Machine learning artificial intelligence system for predicting popular hours

ABSTRACT

A system for generating a graphical user interface in a client device. The system may include a processor in communication with the client device and a database. The processor may execute: receiving a request for occupancy information of a specified merchant; obtaining a plurality of credit card authorizations associated with the merchant; generating a posted transaction array based on the credit card authorizations; removing outlier members of the posted transaction array by applying a threshold filter; generating a transaction frequency array based on the posted transaction array, the transaction frequency array comprising weekdays and aggregated transactions associated with the weekdays; modifying the transaction frequency array by applying a transformation to the aggregated transactions; generating a smoothed array by applying a kernel density estimate to the transaction frequency array; and generating a graphical user interface displaying information in the smoothed array.

PRIORITY CLAIM

This application claims priority from U.S. Provisional Application No.62/487,529, filed Apr. 20, 2017, which is hereby incorporated byreference in the present application.

TECHNICAL FIELD

The present disclosure relates generally to a machine learningartificial intelligence system for modeling hours of operation andpopular hours, and more particularly, to an artificial intelligencesystem to model a merchant's hours of operation and popular hours ofservice using credit card authorization data and machine learning.

BACKGROUND

Consumers often prefer to know whether and when business establishmentsare open for business, to allow them to organize and plan their ownschedules. In addition, consumers prefer to know how busy a merchant isat a given time, to avoid lines and more efficiently access services.There is no central repository, however, as to when all businesses areopen or when the business is busy.

When a credit card is used to pay for a product, the merchant submits arequest to an acquirer bank. The acquirer bank then sends a request toan issuer bank that authorizes or declines the transaction. If thetransaction is approved, the issuer bank provides an authorization codeto the acquirer bank, which notifies the merchant to complete thetransaction. Each request and authorization involved in this processincludes data about the merchant, the consumer, and the transaction. Forexample, credit card authorizations may have time stamps, a merchantidentifier, a transaction amount, and an account number, among otherthings. Therefore, credit card authorizations may be used to makeinferences about the merchant, the consumer, or the transaction.Particularly nowadays, when millions of credit card transactions arerecorded every day, statistical methods can be used to analyze creditcard authorization data, make accurate inferences, and observe trends.

Credit card authorizations are normally generated when a merchant isopen for operation and serving customers. Typically, merchants submitthe credit card authorization requests to the acquirer bank concurrentlywith a consumer making a purchase. Therefore, credit card authorizationscan be used to infer whether the merchant is serving customers and isthus “open.” For example, a restaurant may normally issue multiplecredit card authorization requests between 11 am and 1 pm when it servescustomers during lunch. Thus, it is possible to infer that therestaurant is open between 11 am and 1 pm, based on credit cardauthorization requests. On the other hand, the same restaurant may notissue any credit card authorization requests between 1 am and 2 am.Thus, it is possible to infer that the restaurant is “closed” between 1am and 2 am. Therefore, analysis of credit card authorization data canbe used to predict a merchant's hours of operation.

Moreover, the credit card authorization data can also be used to makeprediction on how busy a merchant is. For example, if a merchant issuesmultiple credit card authorizations within an hour, it is possible toinfer that the merchant is busy during that hour as many customers arepaying services or goods. Alternatively, if a merchant is only issuing afew credit card authorizations, is possible to infer that the merchantis not busy because there is likely not many costumers at that time.

However, making accurate predictions of merchant's hours of operationand merchant's popular hours based on credit card authorization requestdata alone may be challenging for several reasons. First, there may bean imperfect correlation between credit card authorization data andhours of operation. For example, a restaurant may open at 10 am but onlystart issuing credit card authorizations at 10:30 am, when the firstcustomer finishes his or her meal and pays. Similarly, customers may payfor their meals in a restaurant as they leave, so the merchant may bebusy before the credit card authorization is issued. In these examples,the correlations between hours of operation and authorization requestsand between merchant's popular hours and authorization requests areoffset and may lead to prediction errors. Second, data repositories ofcredit card authorizations may store millions of authorizations per day.The large quantity and variety of authorization formats and merchantpractices may make it difficult to effectively process the authorizationdata. Third, the correlations between credit card authorizations andhours of operation or popular hours can be dynamic and may be influencedby externalities. For example, the correlation between authorizationsand hours of operation or popular hours may be influenced by merchantlocation, season, and/or business type. For instance, a merchant mayhave summer hours of operation that are different to the winter hours ofoperation. Similarly, a merchant's popular hours may peak during the endof the year holidays. These are some of the difficulties that makeprediction of hours of operation challenging, but other variables alsoaffect correlations and predictions.

Moreover, predicting popular or busy hours present additionalchallenges. For example, different merchants types may have differentaverage service times. For example, fast food restaurants serve clientsfaster than sit down restaurants. Thus, the same pattern of credit cardauthorizations does not accurately represent the popular or busy hoursfor different merchants. Also, because a single customer may pay formany customers, the number of credit card authorizations may notrepresent how busy is the merchant. Also, some credit cardauthorizations may be generated without a user being in a merchant. Forinstance, credit card authorizations of online purchases for take homefood in restaurants affect the correlation between credit cardauthorization use and busy hours in a merchant. These are additionaldifficulties that make prediction of a merchant's popular hourschallenging.

The disclosed machine learning artificial intelligence system andmodeling methods address one or more of the problems set forth aboveand/or other problems in the prior art.

SUMMARY

One aspect of the present disclosure is directed to an artificialintelligence system for communicating predicted hours of operation to aclient device. The system may include a processor in communication witha client device and a database; and a storage medium storinginstructions. When executed, the instructions in the storage mediumconfigure the processor to: receive, from the client device, a requestfor hours of operation of a merchant, the request specifying a day ofthe week; obtain, from the database in response to the request, a set ofcredit card authorizations associated with the merchant; determine aselected day authorizations subset by selecting, from the set of creditcard authorizations, credit card authorizations issued on the specifiedday of the week; generate a posted transaction array based on theselected day authorizations subset, the posted transaction array mayinclude a plurality of time intervals and numbers of transactions forthe time intervals; generate a predictions list based on the postedtransaction array, the predictions list including the time intervals andprediction indications for the time intervals; and communicate thepredictions list to the client device.

Another aspect of the present disclosure is directed a non-transitorycomputer-readable medium storing instructions that, when executed by aprocessor, cause the processor to operate an artificial intelligencesystem for communicating predicted hours of operation to a clientdevice. The instructions may include receiving, from a client device, arequest for hours of operation of a merchant, the request specifying aday of the week; obtaining, from a database in response to the request,a set of credit card authorizations associated with the merchant;determining a selected day authorizations subset by selecting, from theset of credit card authorizations, credit card authorizations issued onthe specified day of the week; generating a posted transaction arraybased on the selected day authorizations subset, the posted transactionarray including a plurality of time intervals and numbers oftransactions for the time intervals; generating a predictions list basedon the posted transaction array, the predictions list including the timeintervals and prediction indications for the time intervals; andcommunicating the predictions list to the client device.

Yet another aspect of the present disclosure is directed to anartificial intelligence method for communicating hours of operation to aclient device , the method including: receiving, from a client device, arequest for hours of operation of a merchant, the request specifying aday of the week; obtaining, from a database in response to the request,a set of credit card authorizations associated with the merchant;determining a selected day authorizations subset by selecting, from theset of credit card authorizations, credit card authorizations issued onthe specified the day of the week; generating a posted transaction arraybased on the selected day authorizations subset, the posted transactionarray including a plurality of time intervals and numbers oftransactions for the time intervals; generating a predictions list basedon the posted transaction array, the predictions list including the timeintervals and prediction indications for the time intervals; andcommunicating the predictions list to the client device.

Yet another aspect of the present disclosure is directed to a system forgenerating a graphical user interface in a client device. The system mayinclude at least one processor in communication with the client deviceand a database; and a storage medium storing instructions. Theinstructions may configure the at least one processor to executeoperations including: receiving, from the client device, a request foroccupancy information of a specified merchant; obtaining, from thedatabase in response to the request, a plurality of credit cardauthorizations associated with the merchant; generating a postedtransaction array based on the credit card authorizations, the postedtransaction array comprising a plurality of time intervals and numbersof transactions for the time intervals; removing outlier members of theposted transaction array by applying a threshold filter; generating atransaction frequency array based on the posted transaction array, thetransaction frequency array comprising weekdays and aggregatedtransactions associated with the weekdays; modifying the transactionfrequency array by applying a linear transformation to the aggregatedtransactions; generating a smoothed array by applying a kernel densityestimate to the transaction frequency array; and generating a graphicaluser interface displaying information in the smoothed array.

Other aspect of the present disclosure is directed to a non-transitorycomputer-readable medium storing instructions that, when executed by aprocessor, cause the processor to operate system for generating agraphical user interface in a client device. The instructions mayinclude: receiving, from the client device, a request for occupancyinformation of a specified merchant; obtaining, from the database inresponse to the request, a plurality of credit card authorizationsassociated with the merchant; generating a posted transaction arraybased on the credit card authorizations, the posted transaction arraycomprising a plurality of time intervals and numbers of transactions forthe time intervals; removing outlier members of the posted transactionarray by applying a threshold filter; generating a transaction frequencyarray based on the posted transaction array, the transaction frequencyarray comprising week days and aggregated transactions associated withthe week days; modifying the transaction frequency array by applying alinear transformation to the aggregated transactions; generating asmoothed array by applying a kernel density estimate to the transactionfrequency array; and generating a graphical user interface displayinginformation of the smoothed array.

Yet other aspect of the present disclosure is directed to a computerimplemented method for generating a graphical user interface in a clientdevice. The method may include: receiving, from the client device, arequest for occupancy information of a specified merchant; obtaining,from the database in response to the request, a plurality of credit cardauthorizations associated with the merchant; generating a postedtransaction array based on the credit card authorizations, the postedtransaction array comprising a plurality of time intervals and numbersof transactions for the time intervals; removing outlier members of theposted transaction array by applying a threshold filter; generating atransaction frequency array based on the posted transaction array, thetransaction frequency array comprising weekdays and aggregatedtransactions associated with the weekdays; modifying the transactionfrequency array by applying a linear transformation to the aggregatedtransactions; generating a smoothed array by applying a kernel densityestimate to the transaction frequency array; and generating a graphicaluser interface displaying information of the smoothed array.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate disclosed embodiments and,together with the description, serve to explain the disclosedembodiments. In the drawings:

FIG. 1 is a block diagram of an exemplary system, consistent withdisclosed embodiments.

FIG. 2 is a block diagram of an exemplary prediction system, consistentwith disclosed embodiments.

FIG. 3 is a block diagram of an exemplary model generator, consistentwith disclosed embodiments.

FIG. 4 is a block diagram of an exemplary database, consistent withdisclosed embodiments.

FIG. 5 is a block diagram of an exemplary client device, consistent withdisclosed embodiments.

FIG. 6 is a flow chart illustrating an exemplary prediction process,consistent with disclosed embodiments.

FIG. 7 is a flow chart illustrating an exemplary prediction listgeneration process, consistent with disclosed embodiments.

FIG. 8 is a flow chart illustrating an exemplary posted transactionarray generation process, consistent with disclosed embodiments.

FIG. 9 is a flow chart illustrating an exemplary prediction modelgeneration process, consistent with disclosed embodiments.

FIG. 10A is an exemplary posted transaction array, consistent withdisclosed embodiments.

FIG. 10B is an exemplary prediction list, consistent with disclosedembodiments.

FIG. 11 is a graph of an exemplary calculation of accuracy as a functionof time intervals, consistent with disclosed embodiments.

FIG. 12 is a group of graphs presenting exemplary ground truth andprediction values as a function of time intervals for control examples,consistent with disclosed embodiments.

FIG. 13 is a group of graphs presenting exemplary ground truth andprediction values as a function of time intervals for testing examples,consistent with disclosed embodiments.

FIG. 14 is a flow chart illustrating an exemplary modified postedtransaction array generation process, consistent with disclosedembodiments.

FIG. 15 is a flow chart illustrating an exemplary popular hours requestprocess, according with disclosed embodiments.

FIG. 16 is a flow chart illustrating an exemplary transaction frequencyarray generation process, consistent with disclosed embodiments.

FIG. 17 is an exemplary aggregator window displaying numbers oftransactions, consistent with disclosed embodiments.

FIG. 18 is a graphic representation of an exemplary data processing flowfor displaying aggregated numbers of transactions, according todisclosed embodiments.

FIG. 19 is a first exemplary graphical user interface for displayingpopular hours, according to disclosed embodiments.

FIG. 20 is a second exemplary graphical user interface for displayingpopular hours, according to disclosed embodiments.

DETAILED DESCRIPTION

The disclosure is generally directed to a machine learning artificialintelligence system for predicting hours of operation or popular hoursof a merchant and communicating them to a client device. The artificialintelligence system may model a merchant's hours of operation andpopular hours using credit card authorization data. In some embodiments,a client device may present to a prediction system a request for amerchant's hours of operation and/or the merchant's popular hours. Theprediction system may analyze credit card authorization data associatedwith the merchant using prediction models. The prediction models may begenerated using machine learning algorithms that study training datasets that associate merchants with corresponding “ground truth,” thatis, information provided by direct observation as opposed to informationprovided by inference. In addition, the prediction models may modify thedata to prevent biasing errors and remove outliers. The machine learningalgorithms may update and tailor the prediction models based on theclient request. The prediction system may output a prediction of hoursof operation and/or popular hours based on the analysis of credit cardauthorizations. In some embodiments, the prediction system may becoupled with databases that store credit card authorizations and usedata processing methods to curate information and facilitate dataanalysis. In other embodiments, the prediction system may improveaccuracy by using iterative methods in which multiple prediction modelsare generated and then aggregated. In yet other embodiments, theprediction system may be hardware configured to efficiently conductfiltering, sorting, and parallel calculation tasks to improve computingtime and cost.

Reference will now be made in detail to the disclosed embodiments,examples of which are illustrated in the accompanying drawings.

FIG. 1 is a block diagram of an exemplary system 100, consistent withdisclosed embodiments. System 100 may be used to predict a merchant'shours of operation or a merchant's busy or popular hours, consistentwith disclosed embodiments. System 100 may include a prediction system110, a model generator 120, financial services system 130, onlineresources 140, client devices 150, merchant systems 160, and databases180. In some embodiments, as shown in FIG. 1, each component of system100 may be connected to a network 170. However, in other embodimentscomponents of system 100 may be connected directly with each other,without network 170.

Financial services system 130 may be a system associated with afinancial service provider, which may be an entity providing financialservices. For example, financial services system 130 may be associatedwith a bank, a credit card issuer, or other type of financial serviceentity that generates, provides, manages, and/or maintains financialservice accounts. Financial services system 130 may store informationabout accounts and include, for example, credit card accounts, loanaccounts, checking accounts, savings accounts, reward accounts, loyaltyprogram accounts, debit card accounts, cryptocurrency accounts, and/orother types of financial service accounts known to those skilled in theart. Financial services system 130 may include infrastructure andcomponents that are configured to generate and/or provide financialservice accounts such as credit card accounts, checking accounts, debitcard accounts, loyalty or reward programs, lines of credit, and thelike. Financial services system 130 may authorize or decline credit cardauthorization requests and may issue authorization codes.

Online resources 140 may include one or more servers or storage servicesprovided by an entity such as a provider of website hosting, networking,cloud, or backup services. In some embodiments, online resources 140 maybe associated with hosting services or servers that store web pages formerchant systems 160. In other embodiments, online resources 140 may beassociated with a cloud computing service such as Microsoft Azure™ orAmazon Web Services™. In yet other embodiments, online resources 140 maybe associated with a messaging service, such as, for example, Apple PushNotification Service, Azure Mobile Services, or Google Cloud Messaging.In such embodiments, online resources 140 may handle the delivery ofmessages and notifications related to functions of the disclosedembodiments, such as credit card authorization creation, credit cardauthorization alerts, and/or completion messages and notifications.

Client devices 150 may include one or more computing devices configuredto perform one or more operations consistent with disclosed embodiments.For example, client devices 150 may include a desktop computer, alaptop, a server, a mobile device (e.g., tablet, smart phone, etc.), agaming device, a wearable computing device, or other type of computingdevice with communications capability. Client devices 150 may includeone or more processors configured to execute software instructionsstored in memory, such as memory included in client devices 150. Clientdevices 150 may include software that when executed by a processorperforms known Internet-related communication and content displayprocesses. For instance, client devices 150 may execute browser softwarethat generates and displays interfaces including content on a displaydevice included in, or connected to, client devices 150. Client devices150 may execute applications that allow client devices 150 tocommunicate with components over network 170, and generate and displaycontent in interfaces via display devices included in client devices150. The disclosed embodiments are not limited to any particularconfiguration of client devices 150. For instance, a client device 150may be a mobile device that stores and executes mobile applications thatprovide functions offered by prediction system 110 and/or onlineresources 140, such as providing information about merchant systems 160.In certain embodiments, client devices 150 may be configured to executesoftware instructions relating to location services, such as GPSlocations. For example, client devices 150 may be configured todetermine a geographic location and provide location data and time stampdata corresponding to the location data.

Merchant systems 160 may include one or more entities that providegoods, services, and/or information, such as a retailer (e.g., Macy's®,Target®, etc.), a grocery store, an entertainment venue (e.g. cinema,theater, museum, etc.), a service provider (e.g., utility company,etc.), a restaurant, a bar, a non-profit organization (e.g., ACLUTM,AARP®, etc.) or other type of entity that provides goods, services,and/or information that consumers (e.g., end-users or other businessentities) may purchase, consume, use, etc. Merchant systems 160 are notlimited to entities associated with any particular business, specificindustry, or distinct field.

Merchant systems 160 may include one or more computing systems, such asservers, that are configured to execute stored software instructions toperform operations associated with a merchant, including one or moreprocesses associated with processing purchase transactions, generatingtransaction data, generating product data (e.g., stock keeping unit(SKU) data) relating to purchase transactions, etc.

In some embodiments, merchant systems 160 may be physical“brick-and-mortar” locations that a consumer may physically visit andpurchase goods and services. Such physical locations may includemerchant paying system 162, which may include computing devices thatperform financial service transactions with consumers (e.g.,Point-of-Sale (POS) terminal(s), kiosks, etc.). Merchant paying system162 may include one or more computing devices configured to performoperations consistent with facilitating purchases at merchant systems160. Merchant paying system 162 may also include back-and/or front-endcomputing components that store data and execute software instructionsto perform operations consistent with disclosed embodiments, such ascomputers that are operated by employees of the merchant (e.g., backoffice systems, etc.).

While merchant paying system 162 is shown within merchant systems 160 inFIG. 1, in some embodiments merchant paying system 162 may be separatedfrom merchant 160. For example, merchant paying system 162 may be adifferent entity that services merchant systems 160. In suchembodiments, merchant systems 160 may provide goods and/or services viaonline solutions. Merchant systems 160 may sell goods via a website tomarket, sell, and process online transactions. Then, merchant payingsystem 162 may provide an infrastructure for online payments.

In some embodiments, merchant paying system 162 may include apoint-of-sale terminal 166. In particular, a financial card purchase maybe carried out by presenting a financial card at a point-of-saleterminal 166. Data associated with the financial card may be provided topayment processor 164, and payment processor 164 may process payment thepurchase. For example, payment processor 164 may generate the creditcard authorization and include the time stamp and information about themerchant.

For each purchase, merchant paying system 162 may collect and/ormaintain data identifying the financial card that has been used to makethe purchases at merchant systems 160. Additionally, merchant payingsystem 162 may collect and/or maintain data identifying a customerassociated with the financial card and/or data identifying a date onwhich the purchase was made. The merchant paying system 162 may collectand/or maintain other data as well. Data collected and/or maintained bymerchant paying system 162 may be provided to databases 180, modelgenerator 120, and/or prediction system 110.

In some embodiments, payment processor 164 may be a device configured tocollect credit card information and issue credit card authorizations.Payment processor 164 may be a magnetic stripe reader that collectscredit card information and connects with a credit card network. In suchembodiments, payment processor 164 may include software to appendinformation to the credit card authorization or issue new notificationsthat facilitate hours-of-operation modeling. For example, paymentprocessor 164 may include a program to flag a credit card authorization,append a time stamp based on a location code (e.g. Zip code™, andspecify the merchant's address.

In some embodiments, to simplify the collection of data, paymentprocessor 164 may also be connected to databases 180. In suchembodiments, payment processor 164 may include a communication devicethat sends information to both financial services system 130 (i.e.,acquirer bank) and databases 180. In such embodiments, when paymentprocessor 164 is used to complete a credit card transaction, paymentprocessor 164 may issue a simplified authorization with only time, date,and location. The simplified authorization may then be transmitted todatabases 180 and be later used by prediction system 110 or modelgenerator 120. The simplified authorization improves transmission ratesand facilitates selection of authorizations for modeling hours ofoperation or popular hours. For instance, simplified credit cardauthorization records may be easier to filter and sort. In yet otherembodiments, payment processor 164 may add information to the creditcard authorization for the prediction model. For example, paymentprocessor 164 may append local time and merchant ID to the authorizationbefore sending it to databases 180 and/or financial services system 130.

Databases 180 may include one or more computing devices configured withappropriate software to perform operations consistent with providingprediction system 110 and model generator 120 with data associated withmerchant systems 160. Databases 180 may include, for example, Oracle™databases, Sybase™ databases, or other relational databases ornon-relational databases, such as Hadoop™ sequence files, HBase™, orCassandra™. Database(s) 180 may include computing components (e.g.,database management system, database server, etc.) configured to receiveand process requests for data stored in memory devices of thedatabase(s) and to provide data from the database(s).

Data associated with merchant systems 160 may include, for example,historical data identifying authorizations associated with financialcards used to make purchases at merchant systems 160. A financial cardmay represent any manner of making a purchase at merchant systems 160. Afinancial card may be, for example, a financial services productassociated with a financial service account, such as a bank card, keyfob, or smartcard. For example, a financial card may comprise a creditcard, debit card, loyalty card, or other similar financial servicesproduct. In some embodiments, a financial card may comprise a digitalwallet or payment application. Thus, a financial card is not limited toa specific physical configuration and may be provided in any formcapable of performing the functionality of the disclosed embodiments. Insome embodiments, a financial card may include or be included in amobile device; a wearable item, including jewelry, a smart watch, or anyother device suitable for carrying or wearing on a customer's person.Other financial cards are possible as well. Data identifying financialcards used to make purchases at merchant systems 160 may include, forexample, dates on which the purchases were made at merchant systems 160and identification of customers associated with the financial cards.

Data associated with merchant systems 160 may further include, forexample, data identifying financial cards, dates on which credit cardauthorizations were issued, and times of the day when credit cardauthorizations were issued. In some embodiments, data associated withmerchant systems 160 may further include data describing merchant payingsystem 162. Data describing merchant systems 160 may include, forexample, data identifying a brand or operator of merchant paying system162, data identifying a merchant type associated with merchant systems160 (e.g., restaurant, grocery, hair cutter, clothing retailer, etc.),data identifying a geographic location of merchant systems 160 (e.g.,Zip code™, county, state, etc.), data describing a point-of-saleterminal 166 used at merchant systems 160 (e.g., terminal manufacturer,terminal hardware, terminal software, etc.), and/or data describing apayment processor 164 used by merchant systems 160 (e.g., processoroperator, processor hardware, processor software, etc.). The datadescribing payment processor 164 used by the merchant systems 160 mayinclude an indication that a reduced authorization is appended to theauthorization.

While databases 180 are shown separately, in some embodiments databases180 may be included in or otherwise related to one or more of predictionsystem 110, model generator 120, financial services system 130, andonline resources 140.

Databases 180 may be configured to collect and/or maintain the dataassociated with merchant systems 160 and provide it to the predictionsystem 110, model generator 120, financial services system 130, andclient devices 150. Databases 180 may collect the data from a variety ofsources, including, for instance, merchant systems 160, paymentprocessor 164, model generator 120, and/or third-party systems (notshown). Other sources of data associated with merchant systems 160 arepossible as well. Databases 180 are further described below inconnection with FIG. 4.

Model generator 120 may include one or more computing systems configuredto generate prediction models to estimate hours of operations usingcredit card authorizations. Model generator 120 may receive or obtaininformation from databases 180, merchant systems 160, online resources140, and financial services system 130. For example, model generator 120may receive credit card authorization records from databases 180 andmerchant systems 160. Model generator 120 may also receive informationabout hours of operation from online resources 140 and financialservices system 130.

In some embodiments, model generator 120 may receive requests fromprediction system 110. As a response to the request, model generator 120may generate one or more prediction models. Prediction models mayinclude statistical algorithms that are used to determine theprobability of an outcome, given a set amount of input data. Forexample, prediction models may include regression models that estimatethe relationships among input and output variables. Prediction modelsmay also sort elements of a dataset using one or more classifiers todetermine the probability of a specific outcome. Prediction models maybe parametric, non-parametric, and/or semi-parametric models.

In some embodiments, prediction models may cluster points of data infunctional groups such as “random forests.” Random forests may comprisecombinations of decision tree predictors. (Decision trees may comprise adata structure mapping observations about something, in the “branch” ofthe tree, to conclusions about that thing's target value, in the“leaves” of the tree.) Each tree may depend on the values of a randomvector sampled independently and with the same distribution for alltrees in the forest. Prediction models may also include artificialneural networks. Artificial neural networks may model input/outputrelationships of variables and parameters by generating a number ofinterconnected nodes which contain an activation function. Theactivation function of a node may define a resulting output of that nodegiven an argument or a set of arguments. Artificial neural networks maygenerate patterns to the network via an ‘input layer’, whichcommunicates to one or more “hidden layers” where the system determinesregressions via weighted connections. Prediction models may additionallyor alternatively include classification and regression trees, or othertypes of models known to those skilled in the art. Model generator 120may submit models to predict hours of operation and to estimate how busymerchant's may be at a time of the day. To generate prediction models,model generator 120 may analyze information applying machine-learningmethods. Model generator 120 may communicate back with prediction system110 via network 170 or other communication avenues. Model generator 120is further described below in connection with FIG. 3.

Prediction system 110 may include one or more computing systemsconfigured to perform one or more operations consistent with modelingthe hours of operation and estimating popular hours of merchant systems160. In some embodiments, prediction system 110 may receive a requestfor information. Prediction system 110 may receive the request directlyfrom client devices 150 or, alternatively, may receive the request fromother components of system 100. For example, client devices 150 may sendrequests to online resources 140, which then sends requests toprediction system 110. The request may specify a merchant, a day of theweek; and/or other parameters, such as a specific date. In otherembodiments, the request may be done for a plurality of merchants and aminimum prediction confidence.

As a response to information requests, prediction system 110 may requestprediction models from model generator 120. The request may includeinformation about the merchant. The request may additionally specify aday of the week. In addition, prediction system 110 may retrieveinformation from databases 180.

Prediction system 110 may generate a prediction result based on theinformation received from the client request and transmit theinformation to the client device. Prediction system 110 may plot theprediction result. Prediction system 110 is further described below inconnection with FIG. 2.

FIG. 1 shows prediction system 110 and model generator 120 as differentcomponents. However, prediction system 110 and model generator 120 maybe implemented in the same computing system. For example, predictionsystem 110 and model generator 120 may be embodied in a single server.

Network 170 may be any type of network configured to providecommunications between components of system 100. For example, network170 may be any type of network (including infrastructure) that providescommunications, exchanges information, and/or facilitates the exchangeof information, such as the Internet, a Local Area Network, near fieldcommunication (NFC), optical code scanner, or other suitableconnection(s) that enables the sending and receiving of informationbetween the components of system 100. In other embodiments, one or morecomponents of system 100 may communicate directly through a dedicatedcommunication link(s).

It is to be understood that the configuration and boundaries of thefunctional building blocks of system 100 have been defined herein forthe convenience of the description. Alternative boundaries can bedefined so long as the specified functions and relationships thereof areappropriately performed. Alternatives (including equivalents,extensions, variations, deviations, etc., of those described herein)will be apparent to persons skilled in the relevant art(s) based on theteachings contained herein. Such alternatives fall within the scope andspirit of the disclosed embodiments.

FIG. 2 is a block diagram of an exemplary prediction system, consistentwith disclosed embodiments. Prediction system 110 may include acommunication device 210, a prediction memory 220, and one or moreprediction processors 208. Prediction memory 220 may include predictionprograms 222 and prediction data 224. Prediction processor 230 mayinclude an authorization selector 232, an authorization aggregator 234,and a prediction engine 236.

In some embodiments, prediction system 110 may take the form of aserver, general purpose computer, mainframe computer, or any combinationof these components. Other implementations consistent with disclosedembodiments are possible as well.

Communication device 210 may be configured to communicate with one ormore databases, such as databases 180 described above. In particular,communication device 210 may be configured to receive from the databasedata associated with merchant systems 160. In addition, communicationdevice 210 may be configured to communicate with other components aswell, including, for example, merchant payment system 166 and modelgenerator 120.

Communication device 210 may include, for example, one or more digitaland/or analog devices that allow communication device 210 to communicatewith and/or detect other components, such as a network controller and/orwireless adaptor for communicating over the Internet. Otherimplementations consistent with disclosed embodiments are possible aswell.

Prediction memory 220 may include one or more storage devices configuredto store instructions used by prediction processor 230 to performfunctions related to disclosed embodiments. For example, predictionmemory 220 may store software instructions, such as prediction program222, that may perform one or more operations when executed by predictionprocessor 230. The disclosed embodiments are not limited to separateprograms or computers configured to perform dedicated tasks. Forexample, prediction memory 220 may include a single prediction program222 that performs the functions of prediction system 110, or predictionprogram 222 may comprise multiple programs. Prediction memory 220 mayalso store prediction data 224 that is used by prediction program(s)222.

In certain embodiments, prediction memory 220 may store sets ofinstructions for carrying out processes to model hours of operation,generate a prediction list of popular hours, and/or generate a postedtransaction array, described below in connection with FIGS. 6-8. Incertain embodiments, prediction memory 220 may store sets ofinstructions for generating graphical objects, such as the onesdescribed below in connection with FIGS. 11 - 13. Other instructions arepossible as well. In general, instructions may be executed by predictionprocessor 230 to perform one or more processes consistent with disclosedembodiments.

In some embodiments, prediction processor 230 may include one or moreknown processing devices, such as, but not limited to, microprocessorsfrom the Pentium™ or Xeon™ family manufactured by Intel™, the Turion™family manufactured by AMD™, or any of various processors from othermanufacturers. However, in other embodiments, prediction processor 230may be a plurality of devices coupled and configured to performfunctions consistent with the disclosure.

Prediction processor 230 may include an authorization selector 232, anauthorization aggregator 234, and a prediction engine 236. In someembodiments, prediction processor 230 may execute software to performfunctions associated with each component of prediction processor 230. Inother embodiments, each component of prediction processor 230 may be anindependent device. In such embodiments, each component may be hardwareconfigured to specifically process data or perform operations associatedwith modeling hours of operation or popular hours, generating predictionmodels and/or handling large data sets. For example, authorizationselector 232 may be a field-programmable gate array (FPGA),authorization aggregator 234 may be a Graphics processing unit (GPU),and prediction engine 236 may be a central processing unit (CPU). Otherhardware combinations are also possible. In yet other embodiments,combinations of hardware and software may be used to implementprediction processor 230.

Authorization selector 232 may request selected credit cardauthorizations from databases 180 based on parameters such as a day ofthe week, a specific merchant, and/or a merchant identification. Inresponse, communication device 210 may receive from databases 180 a setof credit card authorizations. The set of credit card authorizations mayinclude multiple credit card authorizations recorded during a selectableor variable period of time. For example, the period of time may beselected to be at least one year, so the set of credit cardauthorizations represent every season throughout the year. Authorizationselector 232 may select a subset of credit card authorizations that areassociated with a merchant by filtering the data set. In someembodiments, authorization selector 232 may employ techniques such asthe “pidgeonhole” principle, hierarchical verification, and PEXalgorithms, to filter and select credit card authorizations. In someembodiments, authorization selector 232 may compare specific fields ofthe credit card authorization to accept or discard authorizations. Forexample, authorization selector 232 may select credit cardauthorizations using information appended by payment processor 164.

In some embodiments, prediction processor 230 may implementauthorization selector 232 by executing instructions to create anenvironment in which credit card authorizations are selected. In otherembodiments, however, authorization selector 232 may be a separatedevice or group of devices. In such embodiments, authorization selector232 may include hardware configured to carry out filtering tasks. Forexample, to improve performance and minimize costs, authorizationselector 232 may be an SRAM-based FPGA that functions as authorizationselector 232. Authorization selector 232 may have an architecturedesigned for implementation of specific algorithms. For example,authorization selector 232 may include a Simple Risc Computer (SRC)architecture or other reconfigurable computing system.

Authorization aggregator 234 may determine time intervals and create afrequency table for the intervals. The frequency table may represent thenumber of authorizations that were issued during a specific timeinterval for a merchant. Authorization aggregator 234 may create thefrequency table using time stamps associated with the credit cardauthorizations. For example, authorization aggregator 234 may receive agroup of credit card authorizations such as shown in Table 1, below, andcalculate a frequency table of authorizations using the time intervalspresented in Table 2.

TABLE 1 Authorization No. Time Merchant Amount 1458 11:30 A $58 322111:32 A $23 4434 11:45 A $93 6244 12:40 A $11 7985 12:41 A $13 949912:42 A $61 10765 16:40 A $92 12164 16:45 A $24

TABLE 2 Time interval Frequency 11:30-12:00 3 12:30-13:00 2 16:30-17:002

Prediction processor 230 may implement authorization aggregator 234 byexecuting software to create an environment for aggregation of creditcard authorizations. However, in other embodiments authorizationaggregator 234 may include independent hardware with specificarchitectures to improve the efficiency of aggregation or sortingprocesses. For example, authorization aggregator 234 may be a GPU arrayconfigured to sort credit card authorizations. In some embodiments,authorization aggregator 234 may be configured to implement sortingalgorithms such as, for example, radix sort. Alternatively oradditionally, authorization aggregator 234 may be configured toimplement a programming interface, such as Apache Spark, and executedata structures, cluster managers, and/or distributed storage systems.For example, authorization aggregator 234 may include a resilientdistributed dataset that is manipulated with a standalone softwareframework and/or a distributed file system.

Prediction engine 236 may calculate a prediction indication based on oneor more models and a selected credit card authorization data set. Forexample, prediction engine 236 may use a model from model generator 120and apply inputs based on a posted transaction array to generate aprediction list of hours of operation for merchant 160. In otherembodiments, prediction engine 236 may calculate a prediction of amerchant's busy hours.

Prediction engine 236 may be implemented by prediction processor 230.For example, prediction processor 230 may execute software to create anenvironment to execute models. However, in other embodiments predictionengine 236 may include hardware configured to carry out paralleloperations. Some hardware configurations improve the efficiency ofcalculations, particularly when multiple calculations are beingprocessed in parallel. For example, prediction engine 236 may includemulticore processors or computer clusters to divide tasks and quicklyperform calculations. In some embodiments, prediction engine may receivea plurality of models from model generator 120. In such embodiments,prediction engine 236 may include a scheduling module. The schedulingmodule may receive models and assign the models to independentprocessors or cores. In other embodiments, prediction engine 236 may beFPGA Arrays to provide greater performance and determinism.

The components of prediction system 110 may be implemented in hardware,software, or a combination of both, as will be apparent to those skilledin the art. For example, although one or more components of predictionsystem 110 may be implemented as computer processing instructionsembodied in computer software, all or a portion of the functionality ofprediction system 110 may be implemented in dedicated hardware. Forinstance, groups of GPUs and/or FPGAs maybe used to quickly analyze datain prediction processor 230.

FIG. 3 is a block diagram of an exemplary model generator, consistentwith disclosed embodiments. Model generator 120 may include a trainingdata module 330, a model processor 340, a model memory 350, and acommunication device 360.

One of the fundamental challenges in obtaining accuratehours-of-operation predictions based on credit card authorization datais the lack of sufficient training data sets. Training data sets aresets of data used to discover potentially predictive relationships. Theymay include an input vector and an answer vector, that are used togetherto train an AI machine or a knowledge database. A training data set mayonly be sufficient when it includes a number of samples that enables anartificial intelligence machine or a regression model to be “trained”(e.g., initialized) with an acceptable confidence interval. Sufficienttraining data sets may include samples that represent the fulldistribution to be modeled and have enough samples to identify outliersand minimize deviations. In some embodiments, training data sets includea validation subset and a test subset. In such embodiments, each one ofthe subsets must include a representative sample size.

In some embodiments, training data sets associate credit cardauthorizations with ground truth hours of operation, that is, actualhours of operation information as specified by merchants and obtaineddirectly or indirectly from the merchants. Training data sets mayinclude information of brick-and-mortar merchants with “open” and“closed” hours, permanently closed merchants as negative controls (e.g.,merchants that changed locations), and permanently open merchants aspositive controls (e.g., online retailers). While collecting credit cardauthorization information issued by merchant systems 160 can be done byretrieving information from databases 180 or financial services system130, there is no central source for ground truth of the hours ofoperation of merchant systems 160. In some embodiments model generator120 may include a training data module 330 that monitors network 170 andonline resources 140 to capture ground truth and facilitate generatingthe training data set. Training data module 330 may combine and selectinformation to generate the training data sets used to generateprediction models.

Training data module 330 includes an event detector 310, a ground truthanalyzer 320, and a training filter 332.

Event detector 310 may be a software or hardware module configured todetect events in network 170 that may be relevant to model generator120. In some embodiments, event detector 310 may be configured to detectwhen merchant systems 160 issue a credit card authorization. In suchembodiments, event detector 310 may signal model generator 120 torequest the authorization information and build the training data set.In addition, event detector 310 may be configured to detect changes inonline resources 140. For example, online resources 140 may include websites operated by merchant systems 160. If the website is updated, eventdetector 310 may detect changes and request that ground truth analyzer320 investigate the changes and update records. Event detector 310 maycreate a system to automatically update a training data set of hours ofoperation. Event detector 310 may detect merchant systems 160 that areactively issuing credit cards, and may have the ability to monitorchanges of ground truth to automatically generate a training data set.

Merchant hours of operation and popular hours are dynamic. For example,businesses change their hours of operation, and temporarily orpermanently open or close new locations. Event detector 310 mayfacilitate updating databases to keep up-to-date information bymonitoring the network 170 and flagging transactions that can be used inthe training data set.

Ground truth analyzer 320 may include software or hardware modulesconfigured to collect and organize data that is associated with merchantsystems 160. For example, ground truth analyzer 320 may be configured tocollect hours of operation from online resources 140. Ground truthanalyzer 320 may collect information using a “bot,” such as a webscraper, to automatically fetch and extract information from websitessuch as yellowpages.com™, Google™, or Yelp™. In some embodiments, groundtruth analyzer 320 may download source code of web pages and parse,search, reformat, and copy data. Ground truth analyzer 320 may sortinformation to select information about merchant systems 160.

In some embodiments, ground truth analyzer 320 may use text patternmatching, HTML parsing, vertical aggregation, or semantic annotationrecognizing, among other processes. Ground truth analyzer 320 mayinclude tools to look for hours of operation. For example, in someembodiments a web scraper may be configured to look for text formats of“XX:XX-XX:XX” where X is a digit. In other embodiments, a web scrapermay be configured to recognize labels in HTML code such as “<timeitemprop=“openingHours”>, “<datetime=“Tu,Th 13:00-20:00”>,” or “<p>Open:Monday-Thursday 9 am-noon</p>.”

In other embodiments ground truth analyzer 320 may include crowd-sourcedservices to obtain information about a merchant. In yet otherembodiments, ground truth analyzer 320 may include a verificationservice that uses phone calls to retrieve information. For example,ground truth analyzer 320 may include an automated calling service thatcalls merchants phone numbers. In such embodiments, ground truthanalyzer 320 may determine whether the merchant is open or closed basedon the phone call response. For example, ground truth analyzer 320 mayinclude auto dialer software that calls merchants. Ground truth analyzer320 may determine that the businesses are open any time merchant systems160 pick up the phone but assume merchant systems 160 are closed ifthere is no answer.

Training data module 330 may include software or hardware modulesconfigured to create a training data set. Training data module 330 maycreate the training data set by combining credit card authorizationsfrom a group of merchants and ground truth information for the samegroup of merchants. For example, communication device 360 may receive acollection of credit card authorizations generated by a group ofmerchants. If ground truth analyzer 320 has identified hours ofoperation about the same group of merchants, training data module 330may combine these data sets to create a training data set that includescredit card authorizations and ground truth for a group of merchants.

Model processor 340 may include a processor similar to predictionprocessor 230. Model processor may include a data normalizer 342, atraining data filter 344, and accuracy estimator 348, and a modelbuilder 346.

Data normalizer 342 may include hardware or software modules configuredto normalize information under certain parameters. For example, datanormalizer 342 may normalize time stamps by expressing them in a commonlocal time zone or in UTC time. Alternatively, data normalizer 342 mayadjust time stamps based on a Zip code™ associated with a merchant thatissued a credit card authorization request.

Training data filter 344 may have a similar configuration toauthorization selector 232 but instead of filtering credit cardauthorizations associated with merchant systems 160, training datafilter 344 may select a training data subset before it is used togenerate models. The accuracy of the model used to predict hours mayvary significantly when different data sets are used. For example,predicting hours of operation of a restaurant using a training data setthat is based on grocery stores may undermine the prediction's accuracy.For this reason, training data filter 344 may be configured to selecttraining data sets based on, for example, the category of the merchantin client devices 150 requests. Then, the training data set may beconstrained to certain types of credit card authorizations or models.

Model builder 346 may be software or hardware configured to createprediction models based on the training data. In some embodiments, modelbuilder 346 may generate decision trees. For example, model builder 346may take training data to generate nodes, splits, and branches in adecision tree. Model builder 346 may calculate coefficients and hyperparameters of a decision tree based on the training data set. In otherembodiments, model builder 346 may use Bayesian algorithms or clusteringalgorithms to generate predicting models. In yet other embodiments,model builder 346 may use association rule mining, artificial neuralnetworks, and/or deep learning algorithms to develop models. In someembodiments, to improve the efficiency of the model generation, modelbuilder 346 may be hardware configured to generate models for hours ofoperation or popular hours. For example, model builder 346 may be anFPGA.

Accuracy estimator 348 may be software or hardware configured toevaluate the accuracy of a model. For example, accuracy estimator mayestimate the accuracy of a model, generated by model build 346, by usinga validation dataset. In some embodiments, the validation data set is aportion of the training data set, that was not used to generate theprediction model. Accuracy estimator may generate error rates for eachone of the prediction models. Accuracy estimator 348 may additionallyassign weight coefficients to models based on the estimated accuracy.

FIG. 4 is a block diagram of an exemplary database 180, consistent withdisclosed embodiments. Database 180 may include a communication device402, one or more database processors 404, and database memory 410including one or more database programs 412 and data 414.

In some embodiments, databases 180 may take the form of servers, generalpurpose computers, mainframe computers, or any combination of thesecomponents. Other implementations consistent with disclosed embodimentsare possible as well.

Communication device 402 may be configured to communicate with one ormore components of system 100, such as merchant systems 160, predictionsystem 110, model generator 120, and/or financial services system 130.In particular, communication device 402 may be configured to provide tothe prediction system 110 and model generator 120 data associated with anumber of merchants.

Communication device 402 may be configured to communicate with othercomponents as well, including, for example, one or more merchant paymentsystems, such as merchant payment system 166 described above, and one ormore financial services system 130 and/or online resources 140.Communication device 402 may take any of the forms described above forcommunication device 210.

Database processors 404, database memory 410, database programs 412, anddata 414 may take any of the forms described above for predictionprocessors 230, memory 220, prediction programs 222, and prediction data224, respectively. The components of databases 180 may be implemented inhardware, software, or a combination of both hardware and software, aswill be apparent to those skilled in the art. For example, although oneor more components of databases 180 may be implemented as computerprocessing instruction modules, all or a portion of the functionality ofdatabases 180 may be implemented instead in dedicated electronicshardware.

Data 414 may be data associated with multiple merchants, such asmerchants of merchant systems 160. Data 414 may include, for example,credit card authorization data. Data 414 may describe purchases made bycustomers at merchants using financial cards.

FIG. 5 is a block diagram of an exemplary client device, consistent withdisclosed embodiments. In one embodiment, client devices 150 may includeone or more processors 502, one or more input/output (I/O) devices 504,and one or more memories 510. In some embodiments, client devices 150may take the form of mobile computing devices such as smartphones ortablets, general purpose computers, or any combination of thesecomponents. Alternatively, client devices 150 (or systems includingclient devices 150) may be configured as a particular apparatus,embedded system, dedicated circuit, and the like based on the storage,execution, and/or implementation of the software instructions thatperform one or more operations consistent with the disclosedembodiments. According to some embodiments, client devices 150 maycomprise web browsers or similar computing devices that access web siteconsistent with disclosed embodiments.

Processor 502 may include one or more known processing devices, such asmobile device microprocessors manufactured by Intel™, NVIDIA™, orvarious processors from other manufacturers. The disclosed embodimentsare not limited to any specific type of processor configured in clientdevices 150.

Memory 510 may include one or more storage devices configured to storeinstructions used by processor 502 to perform functions related todisclosed embodiments. For example, memory 510 may be configured withone or more software instructions, such as programs 512 that may performone or more operations when executed by processor 502. The disclosedembodiments are not limited to separate programs or computers configuredto perform dedicated tasks. For example, memory 510 may include a singleor multiple programs 512 that perform the functions of the clientdevices 150. Memory 510 may also store data 314 that is used by one ormore programs 512.

In certain embodiments, memory 510 may store an hours-of-operationapplication 514 that may be executed by processor(s) 502 to perform oneor more prediction processes consistent with disclosed embodiments. Incertain aspects, hours-of-operation application 514, or another softwarecomponent, may be configured to request predictions from predictionsystem 110 or determine the location of client devices 150. Forinstance, these software instructions, when executed by processor(s) 502may process information to generate a request for hours of operation.

I/O devices 504 may include one or more devices configured to allow datato be received and/or transmitted by client devices 150 and to allowclient devices 150 to communicate with other machines and devices, suchas other components of system 100. For example, I/O devices 504 mayinclude a screen for displaying optical payment methods such as QuickResponse Codes (QR), or providing information to the user. I/O devices504 may also include components for NFC communication. I/O devices 504may also include one or more digital and/or analog devices that allow auser to interact with client devices 150 such as a touch-sensitive area,buttons, or microphones. I/O devices 504 may also include one or moreaccelerometers to detect the orientation and inertia of client devices150. I/O devices 504 may also include other components known in the artfor interacting with prediction system 110, merchant systems 160, and/orfinancial services system 130.

The components of client devices 150 may be implemented in hardware,software, or a combination of both hardware and software, as will beapparent to those skilled in the art.

FIG. 6 is a flow chart illustrating an exemplary prediction process 600,consistent with disclosed embodiments. In some embodiments, predictionprocess 600 may be executed by prediction system 110.

In step 602, prediction system 110 may receive requests for hours ofoperation from client devices 150, or other components of system 100.These requests may come in the form of an internet protocol message, aquery data packet, or a port opening instruction, and may furtherinclude information of client devices 150 and specify one or moremerchant systems 160. For example, the requests may specify names and/oridentification numbers of a specific merchant system 160. The requestsmay also specify a day of the week to be used as a parameter to predictopening and closing times and/or a location associated with clientdevices 150 and merchant systems 160.

In step 604 prediction system 110 may obtain credit card authorizationsassociated with the one or more merchant systems 160 specified in therequests. For example, prediction system 110 may query databases 180 toobtain all the credit card transactions that have been issued by themerchant systems 160 associated with the requests. In some embodiments,prediction system 110 may limit the query to a subset of the credit cardauthorizations issued by merchant systems 160. For example, predictionsystem 110 may request only credit card authorizations that have beenissued for a specific day. Also, prediction system 110 may requestcredit card authorizations issued in the last year, in the last month,or between two dates.

In step 606, prediction system 110 may filter, or select, a portion ofthe data received from the database based on information contained inthe received requests. For example, in embodiments where predictionsystem 110 retrieves all credit card authorizations issued by amerchant, prediction system 110 may select credit card authorizationsissued on the day of the week specified in the request. In otherapplications, prediction system 110 may select only credit cardauthorizations above certain dollar amount. In yet other applications,prediction system 110 may receive a set of credit card authorizationsand determine a subset of credit card authorizations based on therequests. For example, prediction system 110 may determine a subset ofcredit card authorizations based on day of the week specified by therequest.

In some embodiments, prediction system 110 may filter the credit cardauthorization data retrieved from databases 180 to simplify futureanalysis. In such embodiments, authorization selector 232 may curate andclassify credit card data authorizations. For example, authorizationselector 232 may use information from the requests issued by clientdevices 150 to create a subset of credit card authorizations.Authorization selector 232 may use information associated with creditcard authorizations to select or discard authorizations. For example,authorization selector 232 may discard authorizations that are notgenerated in within the specified day of the week. Also, authorizationselector 232 may remove transactions considered abnormal. For example,authorization selector 232 may disregard authorizations that have adollar amount significantly different from the other authorizations.Such authorizations may represent credit card activity that is notrelated with hours of operation. For example, a merchant that wholesalesto other businesses may make large sales after hours to a selecteddistributor while the merchant is not being open to the public. Thosetransactions that do not correlate with hours of operation may befiltered based on transaction amount or other related parameters.

In some embodiments prediction system 110 and authorization selector 232may use data-mining algorithms to efficiently curate, parse, and/orfilter the credit card authorizations. For example, prediction system110 may use algorithms such as C4.5, Support Vector Machines, Apriorialgorithm, Expectation-maximization algorithm, among others, to handlelarge data sets of credit card authorizations.

In step 610 prediction system 110 may determine a total number ofauthorizations for the selected day authorizations subset. In someembodiments, prediction system 110 may aggregate the number ofauthorizations to determine a total number of authorizations for thespecified day of the week.

In step 612, prediction system 110 may determine whether the quantity ofcredit card authorizations is sufficient to make an accurate prediction.In some embodiments, prediction system 110 may determine a thresholdnumber of transactions over a period of time. For example, predictionsystem 110 may set a threshold of 50 transactions over a 5-month period.If the threshold is not met, then prediction system 110 may determinethat the quantity of authorizations is insufficient. In otherembodiments, prediction system 110 may determine that the quantity ofcredit card authorizations is not sufficient if the oldest record isless than 5 months old. In yet other embodiments, prediction system 110may determine the quantity is not sufficient if a requested predictionaccuracy cannot be met with the available records. For example, clientdevices 150 may request a minimum prediction accuracy of 90%. Predictionsystem 110 may determine a minimum quantity of credit cardauthorizations required to achieve the requested prediction accuracy. Ifthe available quantity of credit card authorizations is less than thedetermined minimum, prediction system 110 may return an error messagereporting that there are not enough records to make the prediction.

If prediction system 110 determines that there is not enough data,process 600 continues to step 614, in which the prediction system mayreturn an error message. In some embodiments, the error message may besent to online resources 140 which then may send a message to clientdevices 150. In such embodiments, online resources 140 may transmitdefault values for hours of operation to client devices 150 or simplynot send any data for hours of operation. Additionally or alternatively,prediction system 110 may send the error message to merchant systems 160to indicate that potential customers cannot access hours of operation.Alternatively, if prediction system 110 determines that there is enoughdata, it continues to step 616.

In step 616, prediction system 110 determines time intervals for thehours of operation analysis, for example, 30 minutes. In someembodiments, the time intervals may be determined based on aclassification for a merchant of a specified merchant system 160. Inother embodiments, the time intervals may be based on the requests forinformation. In yet other embodiments, prediction system 110 maydetermine time intervals based on time rules.

Time rules may instruct prediction system 110 to determine timeintervals with equal time length that do not overlap each other. Also,time rules may instruct prediction system 110 to have time intervalswherein the sum of time lengths equals one day. Time rules mayadditionally instruct prediction system 110 to determine time intervalsof 30 minutes. For example a full day may be divided in 48-timeintervals of half an hour. Half hour time intervals facilitate theprediction process as they match with standard business hours.Alternatively, time rules may instruct prediction system 110 todetermine time intervals of other or varying length and that may or maynot overlap with each other.

In step 618, prediction system 618 may generate a posted transactionsarray. The posted transaction array may associate the determined timeintervals with an aggregated number of transactions. For example,authorization aggregator 234 may utilize the plurality of times togenerate an array that indicates how many transactions were recorded fora given time period.

In some embodiments, prediction system 110 may adjust the postedtransactions array based on the total number of authorizations for theselected day. For example, authorization aggregator 234 may normalizethe number of aggregated authorizations using the total number oftransactions. In such embodiments, prediction system 110 may use thetotal number of authorizations to prevent over reliance in a singlemerchant. Using the absolute number of transactions to create predictionmodels may result in a model dominated by large merchants that post manytransactions. Such models may be inaccurate when predicting hours ofoperation of smaller merchants or may result in models that have pooradaptation. Thus, prediction system 110 may adjust the postedtransactions using the total number of authorizations to smooth theeffect of large merchants with many transactions and extract patternsthat are insensitive to absolute volume of transactions (e.g.,normalizing).

In step 620, prediction system 110 generates a prediction list. In someembodiments, prediction system 110 generates the prediction list bydetermining, for each one of the time intervals in the postedtransaction array, prediction probabilities. The predictionprobabilities may be calculated using prediction models from modelgenerator 120. Each prediction model may output a model result, whichmay be a probability between 0-100%.

Step 620 may be carried out by prediction engine 236, which may computea probability of a merchant being open or closed. For example, in step620 prediction system 110 may request from model generator 120 one ormore models to predict hours of operation for a selected merchant.Prediction system 110 may then send prediction models and credit cardauthorization data to prediction engine 236 to perform the probabilitycalculations.

In some embodiments, prediction engine 236 may receive a plurality ofmodels from model generator 120 and compute probabilities independentlyfor each one of the models. Prediction engine 236 may then tally theprediction model results. In such embodiments, prediction engine 236 maydetermine accuracy values for the models and model results. For example,based on the evaluation performed by accuracy estimator 348, predictionengine 236 may determine an accuracy value for each model and each modelresult. Then prediction engine 236 may assign weighting coefficients tothe models based on the accuracy values. In such embodiments, predictionengine 236 may modify the computed probabilities for the models (i.e.the model results) using the assigned weighting coefficient to calculatea total prediction. For example, total prediction may be defined by:

${TotalPrediction} = \frac{\sum\limits_{i = 0}^{j}\;{\alpha_{i}*{MR}_{i}}}{N}$

where TotalPrediction is the value to be stored in the prediction list,j is the total number of models retrieved from model generator 120, a isthe assigned coefficient (which is a function of the determineaccuracy), MR is the model result for one prediction model, and N is anormalization value. Thus, prediction engine 236 may add modified treeresults to determine a total prediction. The total prediction may beused to determine a prediction indication, such as “open” or “dosed.”

In step 622, prediction system 110 may communicate the results list tothe client that issued the request. For example, prediction system 110may communicate the request with a list of Boolean values indicatingwhether the merchant is open or closed during each half-hour interval ofthe day for the day of the week as specified in the original request.

FIG. 7 is an exemplary flow chart illustrating a prediction listgeneration process, consistent with disclosed embodiments. Predictionlist generation process 700 may be carried out by prediction system 110.

In step 702, prediction system 110 may determine whether there is aclassification associated with the merchant. For example, predictionsystem 110 may determine if the merchant to be analyzed is a restaurant,a grocery store, a bar, etc. It may do so using the credit cardauthorization data retrieved from the databases 180. For example, insome embodiments prediction system 110 may use Federal IdentificationCodes (FIC) in the credit card authorization requests to determine amerchant classification.

In step 704, prediction system 110 may obtain a model for the merchant.In some embodiments, prediction system 110 may send a request to modelgenerator 120 to generate prediction models for the merchant. Modelgenerator 120 may respond with one or more prediction models for themerchant based on, for example, the classification for the merchant andthe day of the week. For instance, model generator 120 may send toprediction system 110 a group of prediction models specifically forrestaurants open on Saturdays.

In step 706, prediction system 110 may prepare to carry out an iterativecalculation to estimate a prediction indication for each one of the timeintervals. The status of the looping variable is then tested in step708. If the looping variable indicates the iterative process isculminated, prediction system 110 may send the prediction list to theclient in step 710. Alternatively, if the looping variable indicates theiterative process is not culminated, prediction system 110 may continueto step 712 and calculate a prediction for a time interval using thegroup of models. To carry out step 712 prediction system 110 may send arequest for calculation to prediction engine 236.

In step 712, prediction system 110 may tally results of predictionmodels as previously disclosed for step 620 and save the estimated totalprediction in a prediction list in step 716. In some embodiments,prediction system 110 may generate a prediction indication based on thetotal prediction value. In some embodiments, the prediction indicationmay be a Boolean value, such as “open” or “closed” value. In otherembodiments, the prediction indication may represent a status associatedwith the total prediction value. For example, the prediction indicationmay be “likely open,” “likely closed,” “out of business,” or “24/7open.”

In step 718, prediction system 110 may modify the looping variable tocontinue the iterations.

FIG. 8 is an exemplary flow chart illustrating a posted transactionarray generation process, consistent with disclosed embodiments. Postedtransaction array generation process 800 may be carried out byprediction system 110.

In step 802, prediction system 110 may adjust information in the creditcard authorizations. For example, in some embodiments the credit cardauthorizations may comprise time stamps. In such embodiments, predictionsystem 110 may adjust the time stamps in credit card authorizationsbased on a location code associated with merchant systems 160 tofacilitate generating the prediction list. For example, a credit cardauthorization system may always record time stamps in Eastern StandardTime, regardless of merchant's 160 location. Then prediction system 110may adjust the time stamp of the credit card authorization based on alocation code associated with the merchant. For example, predictionsystem 110 may adjust time stamps using the Zip codes™ of merchantsystems 160.

In step 804, prediction system 110 may associate the credit cardauthorization with a time interval. In some embodiments, predictionsystem 110 may sort credit card authorizations using the time stampassociated with the credit card authorizations. In such embodiments,prediction system 110 may utilize sorting algorithms to process data andobtain the categories that associate time intervals and the credit cardauthorizations.

In step 806, prediction system 110 may aggregate the number ofauthorizations issued within the time intervals to generate a frequencytable that quantifies the number of times a credit card authorizationwas issued for in a time interval.

In step 808, prediction system 110 may generate a posted transactionarray using the information of the number of authorizations and data.

FIG. 9 is an exemplary flow chart illustrating a model generationprocess, consistent with disclosed embodiments. In some embodiments,model generator 120 may carry out model generator process 900.

In step 902, model generator 120 may receive a request for predictionmodels. In some embodiments, the request may specify a merchant, a timeof the day, and/or a merchant classification. For example, predictionsystem 110 may send a request for prediction models. The request mayinclude information about merchant systems 160 and/or client devices150.

In step 904, model generator 120 may generate a training data set. Modelgenerator 120 may generate the training data set using information fromdatabases 180, online resources 140, and/or financial services system130. For example, model generator 120 may retrieve, from databases 180,credit card authorizations associated with a group of merchant systems160. Model generator 120 may also collect a ground truth data set, fromthe ground truth analyzer 320, associated with the same group ofmerchants. Training data module 330 may merge or combine these data setsto generate a training data set. In some embodiments, training datamodule 330 may be configured to rate the accuracy of information in thedata set. For example, training data module 330 may create ground truthaccuracy scores for merchant systems 160. When ground truth analyzer ishighly confident of hours of operation for merchant systems 160, forexample ground truth analyzer verified the determined hours of operationon a website of merchant systems 160, then training data module 330 mayassign a high ground truth accuracy score. Alternatively, if groundtruth analyzer 320 is not confident of hours of operation, for examplehours of operation were guessed based on phone calls responded, thentraining data module 330 may assign a low score. Ground truth accuracyscores may enable including more merchant systems 160 in the trainingdata set. Even if the ground truth information is not verified for agroup of merchant systems 160, training data module 330 may stillinclude those merchants and tailor the model's reliance on those sampleswith the ground truth accuracy score.

In some embodiments, training data module 330 may select data based onthe request for a prediction model of step 902. For example, predictionsystem 110 may request a model from model generator 120 for a restauranton Saturday. Training data module 330 may generate a training data setonly using credit card authorization and ground truth only forrestaurants on Saturdays.

In step 906, model generator 120 may create training data subsets bydividing the training data set. In some embodiments, model generator 120may divide the training data set randomly creating random trainingsubsets. Then, prediction models may be generated using the randomlyselected subsets of the training data set. Elements in the training datasubsets may be unique to each subset to create independent training datasubsets. Alternatively, training data subsets may share elements andoverlap. In other embodiments, model generator 120 may divide thetraining data set using division rules.

The training data set division rules may indicate the number ofdivisions and/or ratios between different groups. For example, thetraining data set may be divided using an 80/20 split for testing andvalidation data. Training data division rules may also specify thetraining data set should be divided in three portions. A first portionto calculate coefficients for a model, a second portion used tocalculate hyper parameters associated with a model, and a third portionused to validate and calculate accuracy of the model. Division rules maybe a function of the information included in the request for aprediction model. For example, if the request specifies the model is fora restaurant, model generator 120 may apply a 60/40 split for testingand validation to have stricter accuracy measurements.

Model generator 120 may generate a candidate model using a training dataset. For example, model generator may process the training data set ofstep 906 to determine coefficients (step 908) and hyper parameters (step910) for a prediction model. The prediction models may be parametric,non-parametric, or semi-parametric.

In some embodiments, model generator 120 may create a plurality ofdecision trees as prediction models. For example, model generator 120may use a top-down or a bottom-up approach to generate candidatedecision trees in steps 908 and 910. In such embodiments, modelgenerator 120 may generate nodes by finding a discrete function of theinput attributes values using a training data set or a training datasubset. Based on a splitting metric, a coefficient may be assigned tothe node. Decision trees created by model generator 120 may then be usedin a random forest analysis.

In other embodiments, model generator 120 may generate neural networks,Group Method of Data Handling (GMDH) algorithms, Naive Bayesclassifiers, and/or Multivariate Adaptive Regression Splines. Forexample, model generator 120 may implement Convolutional Neural Networks(CNN), generating nodes and connections associated with multipledimensions using the training data. CNNs consist of multiple layers ofreceptive fields and various combinations of convolutional and fullyconnected layers. Additionally, model generator 120 may implementRecurrent Neural Networks (RNN), generating nodes and connections withdirected cycles that dynamically adjust to behaviors of the trainingdata.

In some embodiments, model generator 120 may generate candidate modelsunder defined constraints. For example, in embodiments in which thegenerated models are decision trees, model generator 120 may beconstrained to have a maximum depth of 10 node levels.

In step 914, model generator 120 may evaluate if the model is completedor if it has reached a stopping criteria. For example, when modelgenerator 120 generates decision trees, in step 914 model generator 120may evaluate if a stopping criteria is fulfilled for the end nodes. Insome embodiments, stopping criteria may be intrinsic to the model ordefined by hyper parameters. For example, the stopping criteria may beachieved when all the samples there is no further classifications orvariables to further split the model. Alternatively, the stoppingcriteria may be defined by user imposed constrains and hyper variables.

If the stop criteria in not fulfilled, model generator 120 may continueto step 916 and select a new variables or parameters to determine newclassifiers. In embodiments in which model generator 120 generates adecision tree, in step 916 model generator 120 may select a new functionfor splitting a subset of the training data set after the first split inthe root node. If the splitting results are above a splitting ratio thenmodel generator 120 may include a new node in the decision tree. Inother embodiments, model generator 120 may continue adding nodes ormodes to the model in step 916. After developing the model, modelgenerator 120 may return to step 914 and evaluate again if the model iscompleted.

Alternatively, when the stop criteria is fulfilled, model generator 120may continue to step 918, in which model generator 120 calculate theaccuracy of the model using a portion of the training data set. Modelgenerator 120 may use, for example, information gain, Gini index,likelihood-ratio chi-square statistics, Dietterich Kearns, and Mansour(DKM) splitting criterion, and/or normalized impurity based criteria toevaluate accuracy of the generated model. In some embodiments, modelgenerator 120 may also generate a receiver operating characteristiccurve to evaluate the performance of a binary classifier.

In step 920, model generator 120 may evaluate whether the accuracy forthe model is above an accuracy threshold. In some embodiments, theaccuracy threshold for the model may be automatically adjusted based onoptimization objectives set for the prediction models. If the model isnot above the threshold (step 920: No) the model may be discarded instep 926. If the calculated accuracy is above the threshold (step 920:Yes), model generator 120 may assign a weighted coefficient to the modelin step 922 and include the model to the set of models in step 924. Theweighted coefficient may associated with the calculated accuracy. Forexample, the weighted coefficient may be proportional to the accuracy.

Process 900 may be repeated a plurality of times to generate a pluralityof models. In some embodiments, model generator 120 may repeat theprocess until a minimum of models is generated. For example, predictionsystem 110 may request that model generator 120 generates models for arandom forest analysis. In such embodiments, model generator 120 maygenerate between 20-100 decision trees to conduct the predictionanalysis. Less than 20 models may not provide the required accuracywhile more than a 100 decision trees may demand too much computingpower. In such embodiments, prediction system may require at least 50decision trees.

FIG. 10A is an exemplary posted transaction array 1010, consistent withdisclosed embodiments. Prediction system 110 may generate postedtransaction array 1010 in, for example, step 618 of FIG. 6. Postedtransaction array 1010 may be issued by authorization aggregator 234,and may associate time intervals 1012 with aggregated number ofauthorizations 1014.

Time intervals 1012 may have a start time and an end time, may bedetermined by prediction system 110, and may have different formats.While FIG. 10A shows independent and sequential time intervals, timeintervals need not be sequential or independent. For example, timeintervals may overlap, or may be non-consecutive.

Aggregated number of authorizations 1014 may indicate the total numberof authorizations that were issued by a merchant during the timeinterval. Prediction system 110 may generate a frequency table by addingthe number of credit card transactions for each time interval.

FIG. 10B is an exemplary prediction list 1020, consistent with disclosedembodiments. In some embodiments prediction list 1020 may be generatedby prediction system 110, for example, at step 620. In such embodimentsprediction list 1020 may be generated by prediction engine 236.Prediction list 1020 may associate time intervals 1022 with a predictionindication 1024.

Prediction time intervals 1022 may be based on transaction time interval1012. In some embodiments, prediction time intervals 1022 may replicatetransaction time intervals 1012. In other embodiments, prediction timeinterval 1022 may be a subset of transaction time intervals. Forexample, some prediction time intervals may group two or moretransaction time intervals if they a have similar number ofauthorizations 1014 to facilitate plotting a minimizing transmissiontime.

Prediction list 1020 may include prediction indications 1024. In someembodiments, prediction indications 1024 may be Boolean and indicatewhether the prediction model calculates the merchant to be open orclosed. In other embodiments, however, prediction indication 1024 may bea category associated with the prediction probability. For example,prediction indication 1024 may assign a label such as “likely open,”“likely closed,” “out of business,” or “24/7 open.”

Prediction list 1020 may include probability values 1026. Probabilityindications 1026 may represent a calculated prediction probability forthe merchant being open at the time intervals. Alternatively,probability indications 1026 may represent a calculated predictionprobability for the merchant being closed at the time intervals.Probability indications 1026 may be based on the model results that areestimated in step 714.

FIG. 11 is a graph of an exemplary prediction accuracy calculation as afunction of a time interval, consistent with disclosed embodiments.Information presented in FIG. 11 may be generated by model generator 120at, for example, step 918.

FIG. 11 presents a plot in which the x-axis presets a time interval, forexample time intervals 1012 (FIG. 10), and the y-axis represent anaccuracy estimation. The accuracy estimation may calculate accuracy ofthe model using a training data subset. The accuracy calculation may beperformed for each one of the time intervals. In some embodiments,accuracy may represent the ratio of correct predictions to the totalnumber of cases evaluated. In other embodiments, accuracy may representthe area under the curve of receiver operating characteristic (ROC)curve. In yet other embodiments, accuracy may represent a positivepredictive value or a sensitivity for a specific criterion value or agroup of criterion values. For example, accuracy may be the positivepredictive value for an optimal criterion based on costs.

FIG. 12 shows graphs of two exemplary comparative results, presenting aground truth and a prediction as a function of a time interval forcontrol merchants, according with disclosed embodiments. The comparativeresults are presented in plots where the X axis represents a timeinterval, for example time intervals 1022 (FIG. 10), and the Y axisrepresents a predicted probability of the merchant being open (for theprediction solid line) and the hours of operation ground truth (dottedline).

Example 1 shows results for a negative control. Merchant in Example 1 isnever open. For example, the merchant in Example 1 may be a closedbusiness. Therefore the ground truth plot shows that the merchant isalways closed. In Example 1, the prediction, calculated by predictionsystem 110 using credit card authorization data, is always low. InExample 1, because the merchant is closed, the merchant does not issueany credit card authorizations. Therefore prediction system 110generates a prediction list with low probabilities for all timeintervals.

Example 2 shows results for a positive control. The merchant in example2 is always open. For example, the merchant in Example 1 is an onlinebusiness that does not close and continuously receives orders and issuescredit card authorizations. Therefore the ground truth plot shows thatthe merchant is always open. In Example 1, the prediction is alwayshigh. In Example 2, the merchant constantly receives orders and issuescredit card authorizations. Therefore, prediction system 110 generates aprediction list with high probabilities for all time intervals.

FIG. 13 shows graphs of exemplary comparative results presenting aground truth and a prediction as a function of a time interval fortesting merchants, according with disclosed embodiments. FIG. 13presents plots similar to the ones in FIG. 12 with the same coordinateaxes. Examples 3-6 show predicted and ground truth hours of operationfor four different merchants.

Merchants of Examples 3-6 open and close within a day. The dotted linerepresents the ground truth of hours of operation while the solid linerepresent the prediction probability of the merchant being open orclosed. Examples in FIG. 13 show that the prediction generally followsthe hours of operation for each merchant. The prediction is low with themerchant is closed while the prediction is high when the merchant isopen.

In some embodiments the prediction can be further classified in a binarystate. For example in some embodiments, prediction system 110 maydetermine any prediction probability above 50% is open while anyprediction below 50% is closed. In other embodiments prediction system110 may classify in different states. For example predictionprobabilities below 25% may have a status of “closed”, predictionprobabilities between 25-50% may have a status of “likely closed,”prediction probabilities between 50-75% may have a status of “likelyopen,” and prediction probabilities between 75-100% may have a status of“open.”

FIG. 14 is an exemplary flow chart illustrating a modified postedtransaction array generation process, according with disclosedembodiments. In some embodiments, process 1400 may be executed by modelgenerator 120. However, in other embodiments process 1400 may beexecuted by prediction system 110.

Model generator 120 may receive a group of credit card authorizationsassociated with a merchant in step 1401. For example, model generator120 may receive credit card authorizations from merchant systems 160,financial services system 130, and/or online resources 140. In someembodiments, model generator 120 may generate arrays of transactions asdiscussed in connection with FIGS. 6 and 10. In such embodiments, modelgenerator 120 may aggregate transactions in an array that associatesdates with number of transactions. The array may additionally associatea specific time interval with number of transactions. In otherembodiments, alternative composite data structures (such as taggedunions or strings) may also store credit card authorization information.

In step 1403, model generator 120 may select an aggregator window.Merchant popularity may be highly seasonal. For example, a merchant thatis popular during the summer may not be popular during winter. Also, anew bar is popular for a couple months but then is no longer busy. Tohave accurate predictions model generator 120 may reduce the sample ofcredit card authorizations for a particular merchant using theaggregator window. The aggregator window may specify an initial date andfinal date. Model generator 120 may determine the initial and finaldates based on the type of merchant associated with the credit cardauthorization. For instance, if the merchant is associated with a themepark, model generator 120 may select a short window of only a couplemonths. However, if the merchant is associated with an airportrestaurant, model generator 120 may select an aggregator window of afull year. In other embodiments, model generator 120 may select anaggregator window based on the periodicity of the number of credit cardtransactions or authorizations.

In step 1405, model generator 120 may eliminate entries outside theaggregator window to limit the sample set that will be used to make thepopular or busy hours prediction.

In step 1407, model generator may determine if transactions in the setof credit card authorizations were proximity transactions, that istransactions in which the credit card was in close proximity to the POSterminal, for example, NFC, chip-read, or swiped transactions. Forsecurity reasons, like preventing unauthorized use, credit cardauthorization information may include metadata of how the transactionwas initiated. For example, credit card authorization metadata mayinclude information of whether the card was swiped in a paymentterminal. This feature becomes relevant for hours of operation andpopular hours prediction because only credit card authorizations thatare swiped are relevant for the predictions. For example, a restaurantmay offer take out services with phone or online purchases. Customersusing the take out service do not crowd the restaurant and, thus, theircredit card authorizations are irrelevant for the predictions. Indeed,these non-swiped transactions may adversely affect the predictionresulting in a higher occupancy prediction. Therefore, in step 1407model generator 120 may review metadata associated with credit cardauthorizations and categorize authorizations as non-swiped (i.e., onlineor telephone purchase). When model generator 120 determines the creditcard transactions include non-swiped transactions (step 1407: yes),model generator 120 may continue to step 1409 and eliminate thenon-swiped transactions. However, if model generator 120 determines thecredit card transactions does not include non-swiped transactions (step1407: no), model generator 120 may continue to step 1411.

In step 1411, model generator 120 may modify the transactions array bymultiplying the number of transactions by an associated transactionamount. For many merchants there is not a direct correlation between thenumber of transactions and the number of customers at the merchant. Forexample, in restaurants a single transaction may be issued for a largetable with multiple customers. Thus, even though there is a singleissued transaction the restaurant may be busy. However, there may be acorrelation between the amount spent in the merchant and the number ofcustomers. For example, the bill in a table of twenty people is largerthan the bill in a table for one person. To improve accuracy of thepopular hours prediction, model generator 120 may modify a transactionor credit card authorization array so it does not merely reflect thenumber of transactions, but it also considers the amount of eachtransaction. In this way model generator 120 may solve inconsistenciesin which a single transaction represents multiple customers. Therefore,in step 1411 model generator 120 may modify the array by multiplying thenumber of transaction by a transaction amount. In such embodiments, asingle transaction that has a large associated amount will represent agreater number of customers in the prediction. In some embodiments, themultiplication of step 1411 may be modified based on the merchant type.For example, in a restaurant the multiplication may include a factor ofan average meal cost to attempt assessing the number of customersassociated with a transaction. Also, in a fast food restaurant, themultiplication number may be factored by the time between transactionsto estimate waiting periods even if the transactions amount are similar.

In step 1413, model generator 120 may modify the array by subtracting aprocessing time from the time interval. For many merchants, customersmay pay at the end of service or at the beginning of service. Therefore,there is not a simple correlation between the popular or busy hours andthe time when the credit card transaction is issued. For example, in arestaurant costumers may pay at the end of the meal. Thus, a transactionthat is issued at 2 pm may be associated with a customer using therestaurant at 1 pm. Alternatively, in a coffee shop a customer pays whenhe arrives, but uses the coffee shop later. Thus, in a coffee shop atransaction issued at 3 pm may reflect the customer being in the coffeeshop from 3 pm-4 pm. To minimize popular hours prediction errors, instep 1413 model generator 120 may subtract or add a time to the timestamp of the transactions in the transaction array. In some embodiments,the added or subtracted time may be uniformly selected for an specifictype of merchant. For example, all merchants classified as restaurantswill be subtracted 30 min or all merchants classified as coffee shopswill be added 15 min. However, in other embodiments, the subtracted timemay be a function hour of the day, predicted hours of operation, or thenumber of transactions recorded for a period of time. For example, intransactions associated with a coffee shop, the added time may be smallfor morning hours but longer for evening hours. Alternatively, if modelgenerator 120 determines multiple transactions in a single hour, thesubtracted time may be greater to account for possible delays duringbusy hours. Therefore, the added or subtracted time of step 1413 may bea function of the number of transactions in a time interval.

In step 1415, model generator 120 may transmit the array of transactionsto a different element of system 100 for further processing. Forexample, model generator 120 may send the array of transactions todatabases 180 or prediction system 110 to be available for generate, forexample, graphical user interfaces.

FIG. 15 is an exemplary flow chart illustrating a popular hours requestprocessing, according with disclosed embodiments. In some embodiments,process 1500 may be executed by prediction system 110. However, in otherembodiments, process 1500 may be processed by other elements of system100.

Prediction system 110 may receive a request for a merchant's popular orbusy hours in step 1502. For example, in some embodiments predictionsystem 110 may receive a request from client devices 150. The requestmay specify a merchant. Alternatively, the request may includeinformation location of client devices 150 and a type of merchant. Forexample, the request may include a merchant type, such as coffee shop,and a general area, such as a postal code. Prediction system 110 maythen determine a specific merchant based on that information andassociate the merchant to the request.

Based on the request received in step 1502, prediction system 110 mayobtain a set of credit card authorizations from databases 180 in step1504. The credit card authorizations retrieved from databases 180 may beassociated with the specific merchant. For example, if the requestincludes “Restaurant X” and “123 Main St,” then prediction system 110may retrieve credit card authorization data associated with the specific“Restaurant X” in “123 Main St.” In some embodiments, prediction system110 may determine that there is not enough transactions for the specificmerchant and craft a prediction based on similar merchants. For example,in some embodiments prediction system 110 may retrieve information ofrestaurants within a radius from “Restaurant X” in “123 Main St.” Theradius used by prediction system 110 may be a function of the number oftransactions available for the specified merchant. For example, if thespecified merchant has a small number of transactions, then the radiusmay be large (i.e., one mile) to collect credit card transactionsassociated with multiple merchants. However, if the specified merchanthas a large number of associated transactions, the radius foraggregating transactions of similar merchants may be small (i.e., onetenth of a mile).

In step 1506, prediction system 110 may generate a posted transactionarray including time intervals and a number of transactions. A similarprocess has been described in connection to step 618 of FIG. 6. In someembodiments, however, prediction system 110 may create a postedtransaction array tailored for popular hours prediction in step 1506.For example, the posted transaction array generated in step 1506 mayhave longer time intervals. Moreover, as explained in connection to FIG.14, the posted transaction array generated in step 1506 may be modifiedto improve accuracy of the popular hours prediction. For example, theposted transaction array generated in step 1506 may be filtered out ofnon-swiped transaction, may have a number of transactions that ismodified by an operation with a transaction amount, and may include timestamps that are modified by a subtraction/addition of time.

Prediction system 110 may remove outliers in step 1508. Outlier data maydecrease the prediction accuracy by modifying the average oftransactions for a day of the week in which there is an abnormally highor low number of transactions. For example, in Thanksgiving there may bea very low number of transactions in a coffee shop or a restaurant. Thislow number of transactions may skew the average number of transactionsfor Thursdays and incorrectly result in a prediction of Thursday beingan unpopular day. To prevent poor predictions, in some embodimentsprediction system 110 may remove outliers. Prediction system 110 mayeliminate outliers by counting the number of transactions associatedwith a unique date and remove dates that do not meet a minimum number oftransactions. For example, prediction system 110 may eliminate any datethat has less than a predetermined number of transaction (e.g., aminimum of three transaction). Alternatively, prediction system 110 mayeliminate days based on a deviation from the mean of number oftransactions. For instance, prediction system 110 may eliminateThursdays in which the number of transaction deviate more than threetimes the standard deviation (3σ) from the mean of the average number oftransactions on Thursday. Alternatively or additionally, predictionsystem 110 may employ other techniques or combination of techniques toremove outliers. For instance, prediction system 110 may use at leastone of Z-Score or Extreme Value Analysis (parametric), Probabilistic andStatistical Modeling (parametric), Linear Regression Models (PCA, LMS),Proximity Based Models (non-parametric), Information Theory Models,and/or High Dimensional Outlier Detection Methods (high dimensionalsparse data), to remove outliers.

After removing outliers, prediction system 110 may down-sample otherdays have a uniform number of samples for each day of the week andfacilitate analysis. For example, after removing outlier dates Fridaymay have only 100 sample date while the other days of the week have200-300 samples. To facilitate data analysis and prevent over or underrepresentation, prediction system 110 may down-sample other days of theweek so each day has 100 samples. In such embodiments, prediction system110 may randomly select the extra dates to be eliminated. Alternatively,prediction system 110 may select dates with lower number of transactionsfor elimination.

An exemplary subroutine that prediction system 110 may perform in step1508 is:

-   -   def sample_trxns_popular_hours(data, datetime_column): # count        n_trxn by date, add weekday column        date_counts=pd.DataFrame(data[datetime_column].dt.date.value_counts(        ), columns=[‘count’])        date_counts[‘weekday’]=date_counts.index.to_datetime( ).weekday        # remove outlier dates (z_score(n_trxn)<3)        z_scores=preprocessing.scale(date_counts[‘count’])        dates=date_counts[abs(z_scores)<3] # count number of dates per        weekday, take min for down-sampling        weekday_counts=dates[‘weekday’].value_counts( )        min_count_weekday=min(weekday_counts) #randomly downsample dates        to min value so weekdays get equal sampling        grouped=dates.groupby(‘weekday’)        idx=np.concatenate([random.sample(grouped.indices[x],        min_count_weekday) for x in grouped.indices])        dates_selected=dates.iloc[idx].index # return selected trxns        return data[data[datetime_column].dt.date.isin(dates_selected)]

In step 1510, prediction system 110 may generate a day-of-the-weekfrequency transaction array based on the posted transaction array.Prediction system 110 may select a time interval and generate afrequency transaction array for each day with the selected timeinterval. For example, prediction system 110 may generate an array thatassociates days of the week (Monday-Sunday), with a time period (everyhour between 9 am to 5 pm), and a number of transactions. In someembodiments instead of the raw number of transaction the frequencytransaction array may associated days of the week and time periods withmodified number of transaction as described in FIG. 14.

Prediction system 110 may generate the array as a two dimensional matrixwhere one dimension is day of the week and the second dimension is timeinterval or time period. Elements in the two dimensional matrix may beaddressed with coordinates like {Monday, 10 am-11 am}. However, in otherembodiments, prediction system 110 may simply generate a one dimensionalarray that specifies in a single dimension day and time interval{“Monday from 10 am-11 am}.

In step 1512, prediction system 110 may apply a linear transformation tothe frequency array to normalize data. To facilitate data manipulation,prediction system 110 may modify the frequency transaction array to, forexample, generate values within [0:1]. For example, in step 1512prediction system 110 may apply a minmax transformation to the number oftransactions. For example, prediction system 110 may perform thefollowing transformation to the number of transactions or the modifiednumber of transactions to create normalized values based on a maximumentry and a base:

base=min(trr)

range=max(trr)−base

normalized=[(x-base)/range for x in trr] Moreover, prediction system 110may

Prediction system 110 may also apply other normalization operations tothe frequency transaction array. For example, prediction system 110 maynormalize data applying variable transformations to normalize the numberof transactions or modified number of transactions (i.e., transactionsmultiplied by an amount) by stripping the rightmost trailing zeros andconverting any result equal to Decimal(‘0’) to Decimal(‘0e0’). Forinstance, Decimal(‘32.100’) and Decimal(‘0.321000e+2’) both normalize tothe equivalent value Decimal(‘32.1’). Alternatively, prediction system110 may use normalization based on mean and standard deviation. Forinstance, prediction system 110 may perform the following operations:

# prepare data for standardization

values=series.values

values=values.reshape((len(values), 1))

# train the standardization

scaler=StandardScaler( )

scaler=scaler.fit(values)

print(‘Mean: % f, StandardDeviation: % f’ % (scaler.mean_,sqrt(scaler.var_)))

# standardization the dataset and print the first 5 rows

normalized=scaler.transform(values)

for i in range(5):

print(normalized[i])

# inverse transform and print the first 5 rows

inversed=scaler.inverse_transform(normalized)

for i in range(5):

print(inversed[i])

Prediction system 110 may additionally generate a smoothed array tominimize noise in the sample of credit card authorizations ortransactions. Thus, prediction system may apply a kernel densityestimate to determine a probability function based on the frequencytransaction array in step 1514. For example, prediction system 110 mayapply a Gaussian kernel density estimation (KDE) with a predeterminedbandwidth selection to generate a smoother array. In other embodiments,however, prediction system 110 may generate the smoothed array applyinga Epanechnikov KDE to optimize the mean square error. In suchembodiments, the Epanechnikov KDE may be selected with a bandwidth of 2.

In some embodiments, prediction system 110 may perform the followingsubroutines to perform steps 1510-1514:

-   -   def popular_hours(trxns, n_trxn_thresh=0): ‘Calculate popular        hours merchant feature from list of transactions # calculate        hour of week for all trxns vals=[x.local_timestamp.weekday(        )*24.+x.local_timestamp.hour+x.local_timestamp.minute/60.+x.local_timestamp.second/3600.        for x in trxns if x.local_timestamp] # return None if        insufficient data if len(vals)<=n_trxn_thresh: return None #        calculate pdf using kernel density estimation        kde=KernelDensity(kernel=‘epanechnikov’,        bandwidth=2.0).fit(vals) # integrate pdf for every hour of the        week probs=[quad(lambda x: np.exp(kde.score(x)), i, i+1)[0] for        i in range(7*24)] # renormalize scores to be in range [0,1]        scores=probs/np.max(probs) return scores

In step 1516, prediction system 110 may respond to the request receivedin step 1502 by generating a graphical user interface. For example, whenthe request is received from client devices 150, prediction system 110may generate a graphical user interface with information of the smoothedarray. The graphical user interface may have an specific arrangement andspecific functions as further described in connection with FIGS. 19-20.

FIG. 16 is an exemplary flow chart illustrating a transaction frequencyarray generation process, according with disclosed embodiments. Process1600 may be performed by prediction system 110. However, in otherembodiments, process 1600 may be performed by other components of system100.

In some embodiments, to effectively generate a prediction of popular orbusy hours it is important to quickly filter credit card authorizationdata to minimize use of computational resources and promptly respond toa client request. Methods previously disclosed for modifying postedtransaction arrays and filtering data may serve this purpose. However,additional filtering processes may be possible by combining theprediction of hours of operation described in connection to, forexample, FIG. 6 and the prediction of a merchant's busy hours. In thisway, prediction system 110 may quickly discard transactions that are notrelevant to the prediction of popular hours based on the prediction ofhours of operation.

In some embodiments, the hours of operation prediction may be utilizedto eliminate transactions that are not swiped. For example, in somesystems metadata of swiped or not-swiped authorizations may not beavailable to prediction system 110. Then, the prediction of hours ofoperation may be used to identify non-swiped authorizations. Under theassumption that transactions outside of hours of operation are notswiped, if prediction system 110 is uncertain of which authorizationsare swiped or not swiped, prediction system 110 may guide thiselimination process with the predicted hours of operation. Thus, toimprove the performance of the prediction of popular or busy hours,prediction system 110 may perform process 1600 to create a more accuratedata set.

In step 1602, prediction system 110 may generate hours of operationprediction for a merchant. For example, prediction system 110 mayrequest model generator 120 to generate a model for hours of operationusing process 900. Prediction system 110 may then generate the hours ofoperation list as described in FIG. 6 or it may also receive theprediction list of hours of operation from a different element of system100. For example, the prediction list of hours of operation may betransmitted from model generator 120 or may have been stored indatabases 180.

In some embodiments, the prediction list may have similar elements tothe arrays described in connection to FIG. 10B. The prediction list ofhours of operation may be for a merchant category or a specificmerchant. For instance, the prediction list of hours of operation maycorrespond to a specific merchant such as “Restaurant X” in “123 MainSt.” Alternatively, the prediction list of hours of operation may be fora merchant category such as a coffee shop brand, or a chain ofrestaurants.

In step 1606, prediction system 110 may receive credit cardauthorizations. These credit card authorizations may be different fromcredit card authorizations that are used to generate the model andcreate the prediction list in processes 600 and/or 900. Usingindependent groups of transactions may improve accuracy of the modelbecause it may prevent biases in the data sets that undermine accuracy.However, in other embodiments the transactions may be the same. Thecredit card authorizations received in step 1606 may be for a specificmerchant from which a user wants to obtain estimated popular hours.

Prediction system 110 may perform a filtering process in step 1608 bydetermining whether there are authorizations outside the predicted hoursof operation in the received set of credit card authorizations. Forexample, prediction system 110 may categorize transactions according totime stamps and determine if any transactions are outside the predictionhours of operation received in step 1604. When there are credit cardauthorizations or transaction outside the predicted hours of operation(step 1608: yes), prediction system 110 may continue to step 1610 andeliminate credit card authorizations not matching the prediction list ofhours of operation. However, when there are not any credit cardauthorizations outside the predicted hours of operation (step 1608: no),prediction system 110 may continue to step 1612 and perform tasks toaggregate data from the credit card authorizations for each day of theweek and then generate a transaction frequency array includingtransactions for each day of the week with only credit cardauthorizations that were issued during the predicted hours of operation.

FIG. 17 is an exemplary aggregator window for number of transactions,consistent with disclosed embodiments. The aggregator window may includean initial date 1702, a final date 1704, and a number of transactions1706 associated with each date between initial date 1702 and final date1704. Any transaction that is outside the aggregator window may beeliminated during data processing by at least one of prediction system110, model generator 120, and/or other elements of system 100.

In certain embodiments, final date 1704 may be a current day and initialdate 1702 may be a predetermined number of days before the current day.For example, initial date 1702 may be 90 days before the current day.

In other embodiments, the selection of initial date 1702 and final date1704 may be guided on the periodicity of number of transaction 1706. Forinstance, in some embodiments a processor in system 100 may perform aDiscrete Fourier Transform (DFT) using the dates as a time variable andnumber of transaction 1706 as the amplitude. In such embodiments, aprocess may look for a peak frequency and match the initial date 1702and final date 1704 so they are equal to one period of number oftransactions 1706. In this way, the aggregator window may be optimizedto captures the different variations in the number of transactions thatmay occur during a period without overanalyzing data that presentsrepetitive information.

Other techniques to assess the periodicity of the number of transactionsmay be also performed to select the aggregation window. For example, aprocessor may implement autocorrelation algorithms to determine a periodof the signal. Additionally or alternatively, a processor may implementSpectral Pattern Matching and/or Cepstrum techniques to identify aperiodicity of the number of transactions and select the amplitude ofthe window based on the determined periodicity.

FIG. 18 is a graphic representation of an exemplary data processing flowfor aggregated number of transactions, according to disclosedembodiments. FIG. 18 describes graphically different data processingsteps that are required to generate histograms of popular or busy hours.

FIG. 18 shows groups of number of transactions for each day of the week.Each day of the week is further divided in time slots. For example, eachday of the week is divided in 24 hours. As shown in the graphicrepresentation, for every hour there is an aggregated number oftransactions. For example, in some embodiments “Monday between 10 am and11 am” may be associated with number of transactions “30” because in thecourse of an aggregation window there were 30 transactions between 10 amand 11 am on Mondays. Moreover, the group of aggregated transactions byday and time of the day may be associated with a specific merchant withat least information about merchant ID 1802 and location ID 1804. Theinitial representation 1810 presents exemplary raw data of anaggregation. Similar information may be stored in transaction frequencyarrays, which describe the number of aggregated transaction in a day ofthe week at a given time interval.

The data in initial representation 1810 may be normalized to generate anormalized representation 1820. For example, as described in FIG. 18 thenumber of transactions may be normalized so values are within theinterval of 0 to 1. This normalization process may be performed with aminmax linear transformation and may facilitate later data processing byparametrizing the credit card authorization information.

The normalized representation may be processed to generate smoothrepresentation 1830 by applying a KDE that outputs a probability densityfunction based on the normalized number of transactions. The smoothingprocess may facilitate prediction by removing noise from themeasurements. For example, in some embodiments, a normal distribution isexpected from the number of transaction in the different days. Thus, astrategy to minimize noise is to apply a KDE that modifies the data tobetter resemble a normal distribution and minimize noise. Smoothrepresentation 1830 represents data after it has been filtered using aKDE. Similar information may be in, for example, the smoothed arraygenerated in step 1514.

Smooth representation 1830 may then be further processed to removeoutliers and/or undesired data points to generate a finalizedrepresentation 1840. Removing outliers minimize errors prediction bydiscarding data points that include abnormal conditions, such asThanksgiving. Also, finalized representation 1840 may eliminateundesired data. For instance, in some scenarios the request for popularhours may be limited for days of the week. Unnecessary information fromweekends may be eliminated in the finalized representation 1840 tofacilitate displaying graphical user interfaces and minimize payload ofdata transmissions.

FIG. 19 is a first exemplary graphical user interface for popular hours,according to disclosed embodiments. Graphical user interface 1900 may begenerated by prediction system 110 and be transmitted for display inclient devices 150. However, in other embodiments, prediction system 110may only transmit information to client devices 150 which may be runningsoftware that interprets data and generates graphical user interfaces.

Graphical user interface 1900 may include top banner 1902, detailswindow 1910, prediction window 1920, and recommendations window 1930.

Top banner 1902 may include information about a merchant. For example,top banner 1902 may include information like merchant ID 1802 andlocation ID 1804.

Details window 1910 may include links associated with the merchant. Forexample, details window 1910 may include a contact link 1912 and awebsite link 1914 associated with the merchant. Website link 1914 mayinclude a hyperlink to a merchant website. Additionally, details window1910 may include an hours of operation prediction 1916. The hours ofoperation prediction 1916 may be based on the information a predictionlist generated by, for example, prediction system 110 in step 620 usingmethods described in connection to FIG. 6.

Prediction window 1920 may include a title that describes the source ofcredit card authorization data that is being used to generate a popularhours prediction. In some embodiments, prediction window 1920 mayinclude a histogram with popular hours representing information of, forexample, the smoothed array generated in step 1514. In otherembodiments, prediction window 1920 may include popularity indicators1922 and day of the week icons 1924. The popularity indicators 1922 maydescribe information how busy is a merchant in a day of the week. Forexample, based on credit card authorizations volume, popularityindicators 1922 may indicate how busy a merchant is on Monday comparedto Tuesday. As it is shown in FIG. 19, popularity indicators may nothave any unit and merely present a graphic representation of themerchant's occupancy every day. However, in other embodiments,popularity indicators 1922 may display a unit such as number oftransactions, or number of transactions multiplied by the transactionsamount. In some embodiments, day of the week icons 1924 may be buttonsfor user interaction. For example, in some embodiments, when a user ofclient devices 150 interacts with day of the week icons 1924 it mayrequest the generation of a secondary user interface that has moreinformation about popular hours for the specific day. For example, if auser selects the Monday icon “M” day of the week icon 1924, the user maybe presented with a secondary graphical user interface such as graphicaluser interface 2000, which is described in connection to FIG. 20.

Recommendations window 1930 may include information of merchants similarto the merchant identified in top banner 1902. For example, if merchantID 1802 identifies a coffee shop, recommendations window 1930 maydisplay a merchant with a similar description. In some embodiments, themerchant displayed in recommendations window 1930 may have a loweroccupancy than the merchant identified in top banner 1902. That is, whenuser inquiries about popular hours of a merchant, graphical userinterface 1900 may additionally display other similar merchants thathave a lower predicted occupancy. In this way, system 100 may directusers to merchants that have similar services but are expected to beless busy. In some embodiments, the recommendation may be based on thelocation of client devices 150. For example, if a merchant is requestingpopular hours of a bank but a bank in a nearby location has a lowerpredicted occupancy, graphical user interface 1900 may display thelocation and expected occupancy of the nearby bank. For example,recommendations window 1930 may display a message such as “ANOTHERBRANCH OF CAPITAL ONE IS EXPECTED TO BE LESS BUSY AND IS LOCATED IN 125MAIN ST.” Additionally or alternatively, the recommendation displayed inrecommendations window 1930 may be based on advertisements paid bymerchant systems 160.

FIG. 20 is a second exemplary graphical user interface for popularhours, according to disclosed embodiments. Graphical user interface 2000may be accessed when a user interacts with day of the week icons 1924.Graphical user interface 2000 may have similar windows to graphical userinterface 1900. For example, graphical user interface 2000 may alsoinclude Graphical user interface 1900 may include a top banner 1902, adetails window 1910, a prediction window 1920, and a recommendationswindow 1930. However, the content of windows in graphical user interface2000 may change.

For example, when a user selects one of the days in graphical userinterface 1900 selecting day of the week icons 1924, graphical userinterface 2000 may modify the content presented in prediction window1920. Instead of showing icons that group the prediction for one day,graphical user interface 2000 may present histogram 2026 for thepredicted popular hours. Histogram 2026 may present predicted occupancyof a merchant at different time intervals for one day of the week. Forexample, as shown in FIG. 20, histogram 2026 may include hourly timeintervals 2022. However, other time intervals of half an hour or fifteenminutes may also be displayed. Histogram 2026 may also include a peaklimit 2024. Peak limit 2024 may be the maximum value that is used forminmax linear transformations to normalize the number of credit cardauthorizations during data processing.

In some embodiments, histogram 2026 may also include one a highlightedprediction 2028. Highlighted prediction may be the maximum expectedoccupancy and may differ from other indications of expected occupancyusing different colors, shapes, or textures.

In some embodiments, each occupancy indicator in histogram 2026 may be abutton that the user can interact with. In such embodiments, therecommendation presented in recommendations window 1930 may be updatedto recommend a similar merchant with a low predicted occupancy at theselected time. For example, a user searched for a burger restaurant andselects the time interval from 1 pm to 2 pm on Tuesday in histogram2026. Graphical user interface 200 may update the information inrecommendations window 1930 to show a different burger restaurant with alower expected occupancy from 1 pm to 2 pm on Tuesday. Like in graphicaluser interface 1900 the merchant displayed in recommendations window1930 may be close to the location of client devices 150 that send thequery for popular hours.

Another aspect of the disclosure is directed to a non-transitorycomputer-readable medium storing instructions that, when executed, causeone or more processors to perform the methods, as discussed above. Thecomputer-readable medium may include volatile or non-volatile, magnetic,semiconductor, tape, optical, removable, non-removable, or other typesof computer-readable medium or computer-readable storage devices. Forexample, the computer-readable medium may be the storage unit or thememory module having the computer instructions stored thereon, asdisclosed. In some embodiments, the computer-readable medium may be adisc or a flash drive having the computer instructions stored thereon.

It will be apparent to those skilled in the art that variousmodifications and variations can be made to the disclosed remote controlsystem and related methods. Other embodiments will be apparent to thoseskilled in the art from consideration of the specification and practiceof the disclosed remote control system and related methods. It isintended that the specification and examples be considered as exemplaryonly, with a true scope being indicated by the following claims andtheir equivalents

1.-20. (canceled)
 21. A system for generating a graphical user interfacein a client device comprising: at least one processor in communicationwith the client device and a database; and a storage medium storinginstructions that configure the at least one processor to executeoperations comprising: receiving, from the client device, a request foroccupancy information of a specified merchant; obtaining, from thedatabase in response to the request, a plurality of credit cardproximity transactions associated with the merchant, the proximitytransactions comprising at least one of NFC, chip-read, or swipedtransactions; generating a posted transaction array based on the creditcard proximity transactions, the posted transaction array comprising aplurality of time intervals and numbers of transactions for the timeintervals; generating a transaction frequency array based on the postedtransaction array, the transaction frequency array comprising weekdaysand aggregated transactions associated with the weekdays, whereingenerating the transaction frequency array comprises modifying the timeintervals of the posted transaction array by subtracting a processingtime; generating a smoothed array by applying a kernel density estimateto the transaction frequency array; and generating a graphical userinterface displaying information in the smoothed array.
 22. The systemof claim 21, the operations further comprising modifying the transactionfrequency array though minmax normalization.
 23. The system of claim 21,wherein generating the transaction frequency array comprises:determining an aggregation window comprising an initial date and a finaldate, the initial date being a predetermined number of days before acurrent day, and the final date being the current day; and eliminating,from the posted transaction array, transactions outside the aggregationwindow.
 24. The system of claim 21, wherein the kernel density estimatecomprises at least one of a Gaussian kernel or an Epanechnikov kernel.25. The system of claim 24, wherein the kernel density estimate is anEpanechnikov kernel with a bandwidth of
 2. 26. The system of claim 21,wherein: the graphical user interface comprises a first graphical userinterface displaying a weekday selection option; and the operationsfurther comprise: receiving a day selection from the client device; andgenerating a second graphical user interface displaying a histogramcorresponding to the day selection.
 27. The system of claim 26, whereinthe first graphical user interface displays a hyperlink to a merchantwebsite.
 28. The system of claim 26, wherein the second graphical userinterface highlights a peak popular hour in the histogram by at leastone of a different color or a different shape.
 29. The system of claim21, wherein generating the transaction frequency array comprises:determining predicted hours of operation based on the posted transactionarray; and eliminating time intervals outside the predicted hours ofoperation from the posted transaction array.
 30. The system of claim 29,wherein: the graphical user interface displays a histogram in a firstwindow; and the graphical user interface displays the predicted hours ofoperation in a second window different from the first window.
 31. Thesystem of claim 29, wherein determining hours of operation comprises:determining a plurality of model results for time intervals in theposted transaction array using a plurality of prediction models, theprediction models outputting corresponding model results; anddetermining prediction indications for the time intervals in the postedtransaction array by tallying the model results.
 32. The system of claim31, wherein the prediction models comprise decision tree modelsconfigured for random forest analysis.
 33. The system of claim 21,wherein generating the posted transaction array comprises applying alinear regression model.
 34. The system of claim 21, wherein theprocessing time is based on numbers of transactions for the timeintervals.
 35. The system of claim 21, wherein the operations furthercomprise: generating a posted transaction array based on the transactionfrequency array, the posted transaction array comprising a plurality oftime intervals and numbers of transactions for the time intervals;determining a plurality of model results for time intervals in theposted transaction array using a plurality of prediction models, eachprediction model outputting a corresponding model result; anddetermining an hours of operation prediction by tallying model results;and the graphical user interface further comprises a details windowdisplaying the hours of operation prediction.
 36. The system of claim26, wherein the histogram comprises a plurality of buttons, each buttonassociated with a day of the week; and the instructions furtherconfigure the at least one processor to execute instructions ofdisplaying a second graphical user interface when a user selects one ofthe plurality of buttons.
 37. The system of claim 26, wherein the secondgraphical user interface comprises a second details window comprising asecond histogram displaying time intervals for a selected day of theweek and predicted occupancies for time intervals.
 38. The system ofclaim 21, wherein the graphical user interface further comprises arecommendations window displaying an alternative merchant associatedwith a category of the specified merchant and located within a thresholddistance of the specified merchant.
 39. A non-transitorycomputer-readable medium storing instructions that, when executed by aprocessor, cause the processor to operate a system for generating agraphical user interface in a client device, the instructionscomprising: receiving, from the client device, a request for occupancyinformation of a specified merchant; obtaining, from a database inresponse to the request, a plurality of credit card proximitytransactions associated with the merchant, the proximity transactionscomprising at least one of NFC, chip-read, or swiped transactions;generating a posted transaction array based on the credit card proximitytransactions, the posted transaction array comprising a plurality oftime intervals and numbers of transactions for the time intervals;generating a transaction frequency array based on the posted transactionarray, the transaction frequency array comprising weekdays andaggregated transactions associated with the weekdays, wherein generatingthe transaction frequency array comprises modifying the time intervalsof the posted transaction array by subtracting a processing time;generating a smoothed array by applying a kernel density estimate to thetransaction frequency array; and generating a graphical user interfacedisplaying information in the smoothed array.
 40. A computer-implementedmethod for generating a graphical user interface in a client device, themethod comprising: receiving, from the client device, a request foroccupancy information of a specified merchant; obtaining, from adatabase in response to the request, a plurality of credit cardproximity transactions associated with the merchant, the proximitytransactions comprising at least one of NFC, chip-read, or swipedtransactions; generating a posted transaction array based on the creditcard proximity transactions, the posted transaction array comprising aplurality of time intervals and numbers of transactions for the timeintervals; generating a transaction frequency array based on the postedtransaction array, the transaction frequency array comprising weekdaysand aggregated transactions associated with the weekdays, whereingenerating the transaction frequency array comprises modifying the timeintervals of the posted transaction array by subtracting a processingtime; generating a smoothed array by applying a kernel density estimateto the transaction frequency array; and generating a graphical userinterface displaying information in the smoothed array.